💾 Archived View for bbs.geminispace.org › u › mbays › 5115 captured on 2024-05-10 at 13:28:12. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-03-21)
-=-=-=-=-=-=-
Ha, I never noticed this, because I always exit insert mode by using alt+[key], where I have my terminal set up so this emits an escape. So alt-l exits insert mode without moving the cursor. I recommend this approach, I couldn't imagine having to reach over to the escape key all the time!
2023-09-04 · 8 months ago
😺 gemalaya · 2023-09-04 at 18:48:
I'm sorry to say that you're wrong. Think about this, if vim didn't go back one character after you press Escape, and leave the cursor where it is, keeping the space character, what would happen if you press 'a' (append) then ? another space ? If vi kept the space char, that would mean you've hit space, which isn't the case.
You're confused by what vi is showing you (that's fine), which is only a (poor) representation of what happens internally with the text buffer. But yeah if you go back to command mode and press 'i', it's weird to have to press 'space' to be able to append text after the last character.
🚀 stack [OP/mod] · 2023-09-05 at 01:45:
@gemalaya, there is no space. The cursor points at the end of line, or buffer, past the last character! If you switch to insert mode, you should be able to insert just there. There never was any space, just the cursor.
why should it matter what mode you are in? And why should changing modes move the cursor? It is just nuts.
🚀 stack [OP/mod] · 2023-09-05 at 03:02:
@mbays, I use jk combo mapped to ESC... But I'll try it your way tomorrow.
😺 gemalaya · 2023-09-05 at 10:43:
@stack I agree, it's confusing. This is a behaviour that was present in the very first versions of vi, and that's still present in vim and forks of vim. You're probably not the first to be infuriated by it :)
🚀 mbays · 2023-09-05 at 13:09:
I think I see what gemalaya meant. In insert mode, it has to be possible to have the cursor beyond the end of the line, as happens with "$a". But that shouldn't be possible in normal mode. So the cursor has to go back one when you exit insert mode in this situation, and then for consistency it makes sense that it always does. I'm almost convinced by this, except... there's still a special case when the cursor is at the start of a line in insert mode, then it stays still on exiting to normal mode. So why is it better to have this as the special case rather than to have the special case be that the cursor moves only if it's off the end of the line? Maybe there's another reason, but maybe it's just that this is how the first vi happened to work and it's far too late to change it now...
🚀 stack [OP/mod] · 2023-09-05 at 13:53:
Yes, I think it's historical. The real problem is that, a terminal cursor is ON a character while insertion happens between characters. Then, given a buffer with 5 characters, there are 6 possible insertion points, while the display is capable of only 5. So to indicate append, the cursor is placed past the buffer, onto an imaginary space where the next character is slated to go. When normal, that position makes less sense, since there is nothing there. But it's still nuts to just move the cursor. Or at least save its insert position and restore on insert if no motion took place.
🚀 stack [OP/mod] · 2023-09-05 at 14:24:
What I just said makes sense _at the end of a buffer or a line_, where the cursor is on fake space created by line-break formatting. Mid-buffer or mid-line what vim does makes no sense at all! All you have to do is treat the cursor as and inclusive start delimiter or non-inclusive end delimiter for operations, or insertion position before the highlighted character on insertion.
It's seems that someone thought that since we need to move the cursor at the end of the line (and we really don't!), we may as well always move the cursor, which is really insane.
The "insertion point" (or cursor) indicates where content is *inserted* (by "i" or "P" for example), and everything under-and-to-the-right of the cursor is shuffled rightward.
An alternative is to append (by "a" or "p" for example), where content is appended *after* the insertion point (and the cursor is moved).
An append operation is essentially a rightward motion followed by an insert. (Note that there is a nice parallel here with delete and backspace.)
😺 gemalaya · 2023-09-06 at 01:48:
@mbays Yes that's what i meant. You make a great point with the "special case". I could be wrong but I think that this behaviour has always been there, all the way back to the first original vi version (that was in 1976 ! omg vi is 47 years old). I wonder if developers of clones like neovim ever considered changing that ..
This never bothered me, i know that if i'm at the end of the line and go back to command mode (and the cursor backs up one char), i'll always use 'a' to add some text.
🚀 stack [OP/mod] · 2023-09-06 at 01:58:
I got into a bit of trouble with a script some months ago, off by a character in a loop...
🐉 gyaradong · 2023-09-06 at 08:15:
I tend to use 'i' or 'a' depending on context, so I don't know why I'd need to keep tapping 'k' after escaping? Having said that, I know the problem and it does make macros a bit error prone sometimes. vi is not very consistent with key choices overall. For example, often a capital letter is the dual of the lowercase letter, but sometimes not. Is it worth chasing that consistency? Not sure. There are new languages / editors which aim for a more consistent modal typing experience.
Off by 1 character — I hate that vim is always off by a character. Let me clarify. When you exit the insert mode, the cursor backs up to the last character entered. So if you insert some text, then delete to the end of the line, vim will eat your last-inserted character unless you move over one. Annoying, right? Or, say you repeatedly enter insert mode then exit back to command line. That is a no-op, right? Wrong: your cursor will move left one character. That seems kind of idiotic. Does...
💬 stack [mod] · 12 comments · 1 like · 2023-09-04 · 8 months ago