So, one of the arguments you’ve made at several points is that we should expect Vim to be slower because it has more choices. This seems incorrect to me, even a simple editor like Sublime Text has about a thousand keyboard shortcuts, which are mostly ad-hoc and need to be memorized separately. In contrast Vim has a small, (mostly) composable language. I just counted lsusr’s post, and it has fewer than 30 distinct components – most of the text is showing different ways to combine them.
The other thing to consider is that most programmers will use at least a dozen editors/IDEs in their careers. I have 5 open on my laptop right now, and it’s not because I want to! Vim provides a unified set of key bindings among practically every editor, which normally have very different ways of doing things.
So that’s on the order of a 10x-100x order of magnitude reduction in vocabulary size, which should at least make you consider the idea that Vim has lower latency.
The issue is not just more choices but more choices to achieve the same result. In programming languages Python achieved a large user-base through being easy to use with it’s core principles like “there should be one obvious way to do things”.
I have 5 open on my laptop right now, and it’s not because I want to! Vim provides a unified set of key bindings among practically every editor, which normally have very different ways of doing things.
The problem is that it’s not dependable when you can use the Vim shortcuts within user editors. If I use IdeaVim in IntelliJ I can use “*y to copy a lot of things to the clipboard but not for example the text in hover popups for which I actually need Crtl+c and where I lose the ability to copy the text when I let Vim overwrite the existing shortcut.
Let’s think about an example. I want to move my cursor.
I might be in a situation when 3W, lllllllllllllllllllllllllllllllll, / with something else $b are all valid moves to get at my target location for the cursor.
This has probably something like 3-5 seconds latency because I not only have to think about where my cursor should go about also about the way to get there.
On the other hand without VIM, having a proper keyboard that makes arrow keys easy to reach I might have a latency of maybe 700 milliseconds.
VIM frequently costs mental processing capacity because I have to model my code in my head in concepts like words (for w and b) that I wouldn’t otherwise.
If you’re using non-modal editing, in that example you could press Alt+rightarrow three times, use cmd+f, the end key (and back one word), or cmd+righarrow (and back one word). That’s not even counting shortcuts specific to another IDE or editor. Why, in your mental model, does the non-modal version feel like fewer choices? I suspect it’s just familiarity – you’ve settled on some options you use the most, rather than trying to calculate the optimum fewest keystrokes each time.
Have you ever seen an experienced vim user? 3-5 seconds latency is completely unrealistic. It sounds to me like you’re describing the experience of being someone who’s a beginner at vim and spent half their life into non-modal editing, and in that case, of course you’re going to be much faster with the second. And to be fair, vim is extremely beginner-unfriendly in ways that are bad and could be fixed without harming experts – kakoune(https://kakoune.org/) is similar but vastly better designed for learning.
As a side note, this is my last post in this conversation. I feel like we have mostly been repeating the same points and going nowhere.
The choices become much more obvious with experience. Waiting 3-5 seconds is completely unrealistic once you know what you are doing. I’d fall back to using the mouse well before 3 seconds, unless I’m in a remote terminal or something that doesn’t support it, in which case I’d use / / ? and n.
You could theoretically target any character in the file using only Space to advance the cursor and gg to go back to the start (well, depending on your settings). But nobody even thinks to do it this way (because it’s stupid), so it doesn’t seem to drain any mental resources not thinking about it.
Similarly, experienced vimmers don’t use hjkl very much.lllllllllllllllllllllllllllllllll is just not something that occurs to you when you think of (and act on) better options first. If you have to use an arrow key more than a few times in a row, you’re doing something wrong. (I mean, sometimes I use js to scroll down as I’m reading, but I’m not going for speed in that case.) By the time you get to about 4-5 keystrokes, you’re better off searching with / / ?.
Similarly, if you have to hit w more than a few times, you’re probably doing something wrong. It’s usually not something that even occurs to me.
I mostly jump around within a line by using f/F and ;/,. It’s faster than going by word with w or by character with h/l. One still has to pick a character or two to target, and for longer jumps, one learns to avoid common characters like vowels, and learn to prefer rarer characters like punctuation. This is just a fast heuristic, I’m not mentally counting character statistics for my current line.
Yes? I mean, other vimmers might feel differently, but I basically don’t use counts like that. Counting to move the cursor is too much effort, especially if you’re counting higher than 2-3. It’s not worth the time it takes.
ww is the same number of keystrokes as 2w. I might use the latter if I needed a single motion operator to repeat later with ., like c2w, but ww or even www would be easier most of the time. Past that, we’re getting to the 4-5 keystrokes where / is better, and you can probably do it in two to three keystrokes with f-something (;) as easily as www.
So rather than counting how many words to get from here to there to find the right number to enter before the w, I’m just looking at the there and hit f, plus whatever character I’m looking at getting to, or a less common one adjacent to it. If the cursor doesn’t quite get there, you can ; a few times. If you overshoot, use , to reverse.
So, one of the arguments you’ve made at several points is that we should expect Vim to be slower because it has more choices. This seems incorrect to me, even a simple editor like Sublime Text has about a thousand keyboard shortcuts, which are mostly ad-hoc and need to be memorized separately. In contrast Vim has a small, (mostly) composable language. I just counted lsusr’s post, and it has fewer than 30 distinct components – most of the text is showing different ways to combine them.
The other thing to consider is that most programmers will use at least a dozen editors/IDEs in their careers. I have 5 open on my laptop right now, and it’s not because I want to! Vim provides a unified set of key bindings among practically every editor, which normally have very different ways of doing things.
So that’s on the order of a 10x-100x order of magnitude reduction in vocabulary size, which should at least make you consider the idea that Vim has lower latency.
The issue is not just more choices but more choices to achieve the same result. In programming languages Python achieved a large user-base through being easy to use with it’s core principles like “there should be one obvious way to do things”.
The problem is that it’s not dependable when you can use the Vim shortcuts within user editors. If I use IdeaVim in IntelliJ I can use “*y to copy a lot of things to the clipboard but not for example the text in hover popups for which I actually need Crtl+c and where I lose the ability to copy the text when I let Vim overwrite the existing shortcut.
Let’s think about an example. I want to move my cursor.
I might be in a situation when 3W, lllllllllllllllllllllllllllllllll, / with something else $b are all valid moves to get at my target location for the cursor.
This has probably something like 3-5 seconds latency because I not only have to think about where my cursor should go about also about the way to get there.
On the other hand without VIM, having a proper keyboard that makes arrow keys easy to reach I might have a latency of maybe 700 milliseconds.
VIM frequently costs mental processing capacity because I have to model my code in my head in concepts like words (for w and b) that I wouldn’t otherwise.
If you’re using non-modal editing, in that example you could press Alt+rightarrow three times, use cmd+f, the end key (and back one word), or cmd+righarrow (and back one word). That’s not even counting shortcuts specific to another IDE or editor. Why, in your mental model, does the non-modal version feel like fewer choices? I suspect it’s just familiarity – you’ve settled on some options you use the most, rather than trying to calculate the optimum fewest keystrokes each time.
Have you ever seen an experienced vim user? 3-5 seconds latency is completely unrealistic. It sounds to me like you’re describing the experience of being someone who’s a beginner at vim and spent half their life into non-modal editing, and in that case, of course you’re going to be much faster with the second. And to be fair, vim is extremely beginner-unfriendly in ways that are bad and could be fixed without harming experts – kakoune(https://kakoune.org/) is similar but vastly better designed for learning.
As a side note, this is my last post in this conversation. I feel like we have mostly been repeating the same points and going nowhere.
The choices become much more obvious with experience. Waiting 3-5 seconds is completely unrealistic once you know what you are doing. I’d fall back to using the mouse well before 3 seconds, unless I’m in a remote terminal or something that doesn’t support it, in which case I’d use
//?andn.You could theoretically target any character in the file using only Space to advance the cursor and
ggto go back to the start (well, depending on your settings). But nobody even thinks to do it this way (because it’s stupid), so it doesn’t seem to drain any mental resources not thinking about it.Similarly, experienced vimmers don’t use
hjklvery much.lllllllllllllllllllllllllllllllllis just not something that occurs to you when you think of (and act on) better options first. If you have to use an arrow key more than a few times in a row, you’re doing something wrong. (I mean, sometimes I usejs to scroll down as I’m reading, but I’m not going for speed in that case.) By the time you get to about 4-5 keystrokes, you’re better off searching with//?.Similarly, if you have to hit
wmore than a few times, you’re probably doing something wrong. It’s usually not something that even occurs to me.I mostly jump around within a line by using
f/Fand;/,. It’s faster than going by word withwor by character withh/l. One still has to pick a character or two to target, and for longer jumps, one learns to avoid common characters like vowels, and learn to prefer rarer characters like punctuation. This is just a fast heuristic, I’m not mentally counting character statistics for my current line.Do you mean that for both doing “4w” and “wwww”?
Yes? I mean, other vimmers might feel differently, but I basically don’t use counts like that. Counting to move the cursor is too much effort, especially if you’re counting higher than 2-3. It’s not worth the time it takes.
wwis the same number of keystrokes as2w. I might use the latter if I needed a single motion operator to repeat later with., likec2w, butwwor evenwwwwould be easier most of the time. Past that, we’re getting to the 4-5 keystrokes where/is better, and you can probably do it in two to three keystrokes withf-something (;) as easily aswww.So rather than counting how many words to get from here to there to find the right number to enter before the
w, I’m just looking at the there and hitf, plus whatever character I’m looking at getting to, or a less common one adjacent to it. If the cursor doesn’t quite get there, you can;a few times. If you overshoot, use,to reverse.