💾 Archived View for bbs.geminispace.org › s › vim › 5135 captured on 2024-08-31 at 15:09:31. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-08-18)
-=-=-=-=-=-=-
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.
2023-09-05 · 1 year ago
🚀 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 · 1 year ago