Why do you believe that you are actually faster with Vim? I used Vim quite a while a bit and it usually still requires thinking to use it. I haven’t seen any evidence that Vim actually makes programs faster that goes beyond programmers feeling faster. Do you have evidence for that, either through measuring your own performance or through another source?
After practicing Vim for a few months, I timed myself doing the Vim tutorial (vimtutor on the command line) using both Vim with the commands recommended in the tutorial, and a click-and-type editor. The click-and-type editor was significantly faster. Nowadays I just use Vim for the macros, if I want to do a particular operation repeatedly on a file.
I think if you get in the habit of double-clicking to select words and triple-clicking to select lines (triple-click and drag to select blocks of code), click-and-type editors can be pretty fast.
I did :Tutor on neovim and only did commands that actually involved editing text, it took 5:46.
Now trying in Sublime Text. Edit: 8:38 in Sublime, without vim mode – a big difference! It felt like it was mostly uniform, but one area where I was significantly slower was search and replace, because I couldn’t figure out how to go backwards easily.
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.
I’ve done pair programming with devs who don’t know vim, and remember on multiple occasions watching the other dev try to make an edit while thinking that I’d be done by now if I was the one typing.
Most of the time, what I do with vim is at the level of habit and “muscle memory”. I don’t have to think about it. If I’m programming a macro or writing a regex, sure, I have to think. But the motion commands just happen now.
For me, Vim isn’t about speed, it’s about staying focused. If I have to move my hand between the keyboard and the mouse every time I want to move the cursor, I lose a little bit of focus. Vim solves this issue by not having to move the placement of your hands. Of course a pointing stick also solves most of these issues.
As far as I know there’s almost no measurement of productivity of developer tools. Without data, I think there are two main categories in which editor features, including keyboard shortcuts, can make you more productive:
By making difficult tasks medium to easy
By making ~10s tasks take ~1s
An example of the first would be automatically syncing your code to a remote development instance. An example of the first would be adding a comma to the end of several lines at once using a macro. IDEs tend to focus on 1, text editors tend to focus on 2.
In general, I think it’s very likely that the first case makes you more productive. What about the second?
My recollection is that in studies of how humans respond to feedback, there are large differences between even relatively short periods of latency. Something like vim gives you hundreds of these (learning another editor’s keyboard shortcuts very well probably does too.) I can point to dozens of little things that are easier with vim, conversely, nothing is harder because you can always just drop into insert mode.
I agree that this isn’t nearly as convincing as actual studies would be, but constructing a reasonable study on this seems pretty difficult.
My recollection is that in studies of how humans respond to feedback, there are large differences between even relatively short periods of latency.
I would expect using VIM to increase latency. While you are going to press fewer keys you are likely going to take slightly longer to press the keys as using any key is more complex.
I can point to dozens of little things that are easier with vim, conversely, nothing is harder because you can always just drop into insert mode.
There’s the paradox of choice and having more choices to accomplish a task costs mental resources. Vim forces me to spent cognitive resources to chose between different alternatives of how to accomplish a task.
All the professional UX people seem to advocate making interfaces as simple as possible.
There’s the paradox of choice and having more choices to accomplish a task costs mental resources.
As your vocabulary has grown, has your speech slowed down? Is it faster to look at the keyboard and type with one finger, or touch-type with all ten? Have you ever played fighting video games? Is someone who knows more moves at a disadvantage? It might depend on how much they’ve practiced them!
More conscious choices slow me down, it’s true, but once it’s ingrained at the level of habit, you can do it almost as fast as you can think it, just like speaking or typing or playing a fighting game. Learning to do it in the first place is slower, but like learning to touch-type, try to get it right before you try to get it fast.
When I touch-type words, I don’t think in terms of individual letters. I don’t move that way either. There are clusters of keystrokes that happen frequently in English text. My other fingers have already started moving to the next letters before I’ve finished pressing the first one. Vim’s motion commands end up feeling the same way. It’s just like typing words.
New vimmer: I need to swap a line with the next one. I should cut it and paste it after. What was the command for that again? D? Uh. Visual mode! hhhhhhhhhhhhhhhhhv. Um. k? no. j. l. $. d. Down? j. p! What? Uh, undo! u! Up? k! p! Why isn’t this working? u! $! i! Enter. Aw screw it! Backspace! Right-arrow, Enter, p! Backspace! Escape, p! Phew!
Intermediate vimmer: I could select the whole line with V and cut with d or do a cut-motion with ^D. 0D is a little easier to reach than ^D though. Or dd. The dd is easiest. Am I still in insert mode? Escape, Escape. dd! Down? Oh, already there. Paste-below with p. p! Done.
Experience vimmer: swap-linesddpdone.
I’m not even thinking in terms of select-copy-paste steps here.ddp is a muscle macro in its own right, just like a common word or a practiced fighting-game move.
Is it faster to look at the keyboard and type with one finger, or touch-type with all ten?
Touch typing doesn’t increase the amount of choices if you do it properly. If you learn touch typing properly there’s a single finger that’s responsible for a single key.
As your vocabulary has grown, has your speech slowed down?
That’s a bad comparison because as my vocabulary grew I also get better got speaking.
In cross language comparisons more choices, do slow down speakers. Speakers of a language with fewer phomenes are faster at speaking a single phoneme then speakers of a language with more different phonemes.
I would expect using VIM to increase latency. While you are going to press fewer keys you are likely going to take slightly longer to press the keys as using any key is more complex.
This really isn’t my experience. Once you’ve practiced something enough that it becomes a habit, the latency is significantly lower. Anecdotally, I’ve pretty consistently seen people who’re used to vim accomplish text editing tasks much faster than people who aren’t, unless the latter is an expert in keyboard shortcuts of another editor such as emacs.
There’s the paradox of choice and having more choices to accomplish a task costs mental resources. Vim forces me to spent cognitive resources to chose between different alternatives of how to accomplish a task.
All the professional UX people seem to advocate making interfaces as simple as possible.
You want simple interfaces for beginners. Interfaces popular among professionals tend to be pretty complex, see e.g. Bloomberg Terminal or Photoshop or even Microsoft Excel.
This really isn’t my experience. Once you’ve practiced something enough that it becomes a habit, the latency is significantly lower.
How much experience do you have with measuring the latency of things to know what takes 400ms and what takes 700ms?
Anecdotally, I’ve pretty consistently seen people who’re used to vim accomplish text editing tasks much faster than people who aren’t, unless the latter is an expert in keyboard shortcuts of another editor such as emacs.
Even if total time for the task is reduced the latency for starting the task might still be higher.
I think about ~1year into using vim, I thought the same thing: I’m doing the same thing, just with more quicker steps, so it feels faster.
But after that I persisted and now it’s actually faster. Part of it is expanding your repertoire and memorizing it (where you don’t have to think about it at all). Also vim editor by itself I still find very clunky, but using vim shortcuts in something like PyCharm is $$$!
For any given thing you want to do imagine what it would take to do it without Vim
This reminds me of the person with whom I was arguing about what takes how long on Anki and who was saying that his own judgement of what takes how long is superior to the Anki statistics where I know how the code works and which actually measures the time correctly.
Human imagination is not good at estimating what tasks have how much latency.
Why do you believe that you are actually faster with Vim? I used Vim quite a while a bit and it usually still requires thinking to use it. I haven’t seen any evidence that Vim actually makes programs faster that goes beyond programmers feeling faster. Do you have evidence for that, either through measuring your own performance or through another source?
After practicing Vim for a few months, I timed myself doing the Vim tutorial (vimtutor on the command line) using both Vim with the commands recommended in the tutorial, and a click-and-type editor. The click-and-type editor was significantly faster. Nowadays I just use Vim for the macros, if I want to do a particular operation repeatedly on a file.
I think if you get in the habit of double-clicking to select words and triple-clicking to select lines (triple-click and drag to select blocks of code), click-and-type editors can be pretty fast.
This is a great experiment, I’ll try it out too. I also have pretty decent habits for non-vim editing so it’ll be interesting to see.
I did :Tutor on neovim and only did commands that actually involved editing text, it took 5:46.
Now trying in Sublime Text. Edit: 8:38 in Sublime, without vim mode – a big difference! It felt like it was mostly uniform, but one area where I was significantly slower was search and replace, because I couldn’t figure out how to go backwards easily.
Interesting, thanks for sharing.
Command-shift-g right?
I ended up using cmd+shift+i which opens the find/replace panel with the default set to backwards.
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.I’ve done pair programming with devs who don’t know vim, and remember on multiple occasions watching the other dev try to make an edit while thinking that I’d be done by now if I was the one typing.
Most of the time, what I do with vim is at the level of habit and “muscle memory”. I don’t have to think about it. If I’m programming a macro or writing a regex, sure, I have to think. But the motion commands just happen now.
For me, Vim isn’t about speed, it’s about staying focused. If I have to move my hand between the keyboard and the mouse every time I want to move the cursor, I lose a little bit of focus. Vim solves this issue by not having to move the placement of your hands. Of course a pointing stick also solves most of these issues.
As far as I know there’s almost no measurement of productivity of developer tools. Without data, I think there are two main categories in which editor features, including keyboard shortcuts, can make you more productive:
By making difficult tasks medium to easy
By making ~10s tasks take ~1s
An example of the first would be automatically syncing your code to a remote development instance. An example of the first would be adding a comma to the end of several lines at once using a macro. IDEs tend to focus on 1, text editors tend to focus on 2.
In general, I think it’s very likely that the first case makes you more productive. What about the second?
My recollection is that in studies of how humans respond to feedback, there are large differences between even relatively short periods of latency. Something like vim gives you hundreds of these (learning another editor’s keyboard shortcuts very well probably does too.) I can point to dozens of little things that are easier with vim, conversely, nothing is harder because you can always just drop into insert mode.
I agree that this isn’t nearly as convincing as actual studies would be, but constructing a reasonable study on this seems pretty difficult.
I would expect using VIM to increase latency. While you are going to press fewer keys you are likely going to take slightly longer to press the keys as using any key is more complex.
There’s the paradox of choice and having more choices to accomplish a task costs mental resources. Vim forces me to spent cognitive resources to chose between different alternatives of how to accomplish a task.
All the professional UX people seem to advocate making interfaces as simple as possible.
As your vocabulary has grown, has your speech slowed down? Is it faster to look at the keyboard and type with one finger, or touch-type with all ten? Have you ever played fighting video games? Is someone who knows more moves at a disadvantage? It might depend on how much they’ve practiced them!
More conscious choices slow me down, it’s true, but once it’s ingrained at the level of habit, you can do it almost as fast as you can think it, just like speaking or typing or playing a fighting game. Learning to do it in the first place is slower, but like learning to touch-type, try to get it right before you try to get it fast.
When I touch-type words, I don’t think in terms of individual letters. I don’t move that way either. There are clusters of keystrokes that happen frequently in English text. My other fingers have already started moving to the next letters before I’ve finished pressing the first one. Vim’s motion commands end up feeling the same way. It’s just like typing words.
New vimmer: I need to swap a line with the next one. I should cut it and paste it after. What was the command for that again? D? Uh. Visual mode!
hhhhhhhhhhhhhhhhhv. Um.k? no.j.l.$.d. Down?j.p! What? Uh, undo!u! Up?k!p! Why isn’t this working?u!$!i! Enter. Aw screw it! Backspace! Right-arrow, Enter,p! Backspace! Escape,p! Phew!Intermediate vimmer: I could select the whole line with
Vand cut withdor do a cut-motion with^D.0Dis a little easier to reach than^Dthough. Ordd. Theddis easiest. Am I still in insert mode? Escape, Escape.dd! Down? Oh, already there. Paste-below withp.p! Done.Experience vimmer: swap-lines
ddpdone.I’m not even thinking in terms of select-copy-paste steps here.
ddpis a muscle macro in its own right, just like a common word or a practiced fighting-game move.Touch typing doesn’t increase the amount of choices if you do it properly. If you learn touch typing properly there’s a single finger that’s responsible for a single key.
That’s a bad comparison because as my vocabulary grew I also get better got speaking.
In cross language comparisons more choices, do slow down speakers. Speakers of a language with fewer phomenes are faster at speaking a single phoneme then speakers of a language with more different phonemes.
This really isn’t my experience. Once you’ve practiced something enough that it becomes a habit, the latency is significantly lower. Anecdotally, I’ve pretty consistently seen people who’re used to vim accomplish text editing tasks much faster than people who aren’t, unless the latter is an expert in keyboard shortcuts of another editor such as emacs.
You want simple interfaces for beginners. Interfaces popular among professionals tend to be pretty complex, see e.g. Bloomberg Terminal or Photoshop or even Microsoft Excel.
How much experience do you have with measuring the latency of things to know what takes 400ms and what takes 700ms?
Even if total time for the task is reduced the latency for starting the task might still be higher.
I think about ~1year into using vim, I thought the same thing: I’m doing the same thing, just with more quicker steps, so it feels faster. But after that I persisted and now it’s actually faster. Part of it is expanding your repertoire and memorizing it (where you don’t have to think about it at all). Also vim editor by itself I still find very clunky, but using vim shortcuts in something like PyCharm is $$$!
How do you know?
For any given thing you want to do imagine what it would take to do it without Vim and it’s just more & usually more awkward key strokes.
I’d say the only place where I still use mouse is to jump to a completely random place in code.
I’ve found that
/is still often faster for that. Not always, but often. I still use the mouse sometimes.This reminds me of the person with whom I was arguing about what takes how long on Anki and who was saying that his own judgement of what takes how long is superior to the Anki statistics where I know how the code works and which actually measures the time correctly.
Human imagination is not good at estimating what tasks have how much latency.