Vim speed is not really the point
I am a Vim user. And a Vim fan.
I was fiddling around for some time, you know, just knowing the basics, because it is convenient to do small changes on servers without having to worry about installing anything. Just the basics, insert mode, some search, save,
and a couple more things. Then, around two years ago, I decided to give it a try as my main editor, after watching a presentation of a co-worker (my boss, actually) about how to use Vim (he has been using Vim for around 20 years)
At the beginning, it is quite difficult, to be honest. You have to relearn everything about editors. But I was doing OK after one or two weeks, so I kept using it. I was also forcing myself into improving my usage, reading about it and learning tricks…
Then, after a while of using it and read a lot of instructional material (I cannot recommend “Practical Vim” by Drew Neil strongly enough. It’s a FANTASTIC book), everything started to make sense. Let’s be serious, the problem with Vim is not exactly that is “difficult” per se, it’s that it is so alien to any other text edition experience, that you have to forget everything that you know about how to edit text. That’s why I don’t agree that the Vim learning curve is a myth. Because, when we first heard of Vim, we already have 10+ years of using things like Word, NotePad or Gmail to write text. We need time to assimilate how to edit text “the Vim way”. And that takes time to assimilate, as your muscular memory works against you.
And, yes, the Vim way is awesome. But it is awesome not for the reason that usually someone will think at the start. There is the perception that Vim is awesome because is fast. It is not.
Well, it can be really fast sometimes, like performing complex replacements or macros. And that is absolutely magical. But that is not something that I use constantly, and it only save a noticeable amount of time when those operations should be performed tens, maybe hundreds of times. Of course, it also will reduce greatly boredom of repetitive tasks. It is still a great win. But those are exceptions on your day-to-day operation. If they are the rule, probably you should consider a change of job!
I have the same expression when looking not commented code.
In my mind it sort of compares with knowing how to touch-type. Developers, contrary to Hollywood opinion, are not typists from the 50s, typing tirelessly for hours and producing massive streams of characters. We write small burst of code between long reading and thinking sessions. The best analogy that I heard (I can’t find the reference on Internet right now 😦 ) is that we act like samurais in anime, just staring at the code, analysing them carefully. Thinking, thinking, thinking. And suddenly, in a blink of an eye, we draw our sword and hit with precision, to then stand still, in a dramatic pose, as we see our enemy cut in half. Touch type is not important because it allows us to generate double or triple number of words per day. It is important because it eases the process of getting out of thoughts at that critical moment. You don’t add speed, you add control and relax. You don’t have to manage the stress of getting your body to press the keys and some symbols appear on the screen. You just think on writing something and it appears on the screen, with your body handling the problem and freeing your mind.
Using Vim feels similar to me. When I have to use another editor, I am thinking in terms of characters, maybe words. But my mental flow is more or less the following:
- I have to change the parameters of this function.
- Decide action: I’ll delete those words between the brackets and write the new params.
- Cursor just right to the starting bracket. CAPS and ALT and right, right, right. Good.*
- Hit Delete
- Write the new params.
- Done.
* This can also be deleting each character, but I’m trying to be an “advanced user” here.
Mentally, I get the following voice inside my head, as I move through the text:
Are we there yet? No. Are we there yet? NO. Are we there yet? NO!!! Wait, YES! Now delete.
While, in the Vim realm, the process is more like the following:
- I have to change the parameters of this function.
- Decide action: I’ll change those words between the brackets.
- Operation change between brackets
- Write the new params.
- Done (hit ESC)
Here, the part when I spend the most energy is in operation 2, determining what is the part I have to change. In this case, is easy, as I set as example something between brackets (ci( will do), but it is a quite common case when you’re editing code. But it can be more difficult, like “up to the character X (coma, semicolon)”. I am getting better with practice, but it is not automatic, I have to think about it. That’s the part where the learning curve kicks in. It’s not about knowing what to do. It’s deciding what (of a myriad possibilities) option is the correct one. Or even if there is one that you don’t know yet that will work better. Move one character at a time? A word? A block? Count the number of lines? Etc… Deciding the proper action without much effort, instinctively, takes practice and conscious teaching yourself possible moves (that you can reuse later for more operations). After all, the code tends to repeat patterns, and there are a lot of actions that helps with specifics of the language, like indenting in Python.
Really, you should get one if you want to learn some Vim. And check vimcasts.org
Anyway, I find this way of operating with the text causes much much less friction in my mind, ad I can see how it gets easier and easier as I am more experienced. Because I am thinking in actions. Actions that make sense. I am not rearranging random characters. I am performing specific actions that make sense semantically. I do stuff with words, phrases, paragraphs, blocks, functions, parameters inside brackets, etc…
And that makes a lot of sense. My mind thinks naturally on that kind of actions, so it’s more natural than rearrange some sort of symbols on a screen.
All the part of reading and thinking takes the same time, and actually using the editor to change the code is a small part of my working day. Saving some keystrokes is not going to allow me going home two hours earlier. And trying to optimise in keystrokes can take a lot of time just thinking.
But, when I make a change, I am able to do it spending less mental energy. It feels more natural. I need to think less in the characters. The editor gets less into the way of getting the text into the image in my mind. I still have to think about what action to do, but it is a much more natural approach.
And that is the power of Vim. Not that is fast. Not that you can do a magical operation with few keystrokes. That it stays out as much as possible of the way between you and your code. That maps your thoughts once you know how to use it.
And that’s why I don’t really care about Vim “speed”. I am not “faster” using Vim. I do not generate noticeable more code at the end of the day. But I generate it with less effort and caring more about the quality than battling with my keyboard. I am more relaxed, more in control, focused in what matters. Caring about getting stuff done. More productive. That’s Vim killer feature.
UPDATE: There is some discussion in Hacker News, if you want to take a look.
Wrong Side of Memphis 
Pingback: Vim speed is not really the point | My Daily Feeds
Thank you for this great article. This makes me want to use vim because now I understand what happnes when we use it which was not the case with the bunch of articles out there about vim saying you’re so much faster with it.
That’s great! I’d recommend to take it easy (it is very weird at the beginning) and try to learn ‘making sense of it’. There are lots of (useful) isolated tricks , but the important part is to understand (and apply instinctively) the basics.
Hmm. I am trying to avoid being rude but that amount of people saying “Vim is fast” may be right…
Vim is not fast for you because you are not really using it right. Keep using it, and abandon all that stuff imposed by the IBM-standard-style editors and you will discover how slow you really are. You actually pointed it out in the paragraph: “Here, the part when I spend the most energy”. You just need more experience and practice to grasp it.
Stuff like using hjkl instead of arrows is important, not because of the time spent in moving the hand over the keyboard, but because it starts teaching your brain that everything can be relearned.
The point with Vim is not it runs macros fast, the point is it lets you map your keyboard directly to your brain.
But Vim is not intuitive, it requires practice and work. Give it the time it needs (also for @Lucian) and you will never come back.
Well, I am faster using Vim. I totally agree on you on that. My argument here is that I don’t use Vim because is faster. I use it because, after learning (and I have still lots of things to learn), it maps better the way to approach editing text.
Yes, it is faster, but the point is not writing faster. It is writing better.
It is the same argument as touch type. I am not generating more text because I know how to touch type. But because I know how to touch type, I don’t have to worry much about writing, so I can focus on WHAT to write. And that’s a great advantage…
I think we are making the same point here 😉
Ok, I think I understand now.
Your are implying that the speed is related to another thing. From that point of view I guess we are using different points and reaching different conclusions, but the results in terms of user experience are the same: you write faster and better.
I am saying “faster is better” and you are saying “better is faster”. It’s nuts. We are saying almost the same thing 😛
I guess that I get your point now: lot of the people who say that “Vim is fast” are somehow implying a deeper motive and you are trying to explain it.
Interesting approach.
Great article, I started the “VIM journey” like you did and I felt the same way when I had to operate on the source files, the process is simple as “identify the change you have to do and do it using the semantic of VIM, press ESC, done..feel good :)”
if have five minutes have a look at my little post on VIM http://blog.pischedda.info/posts/2013/01/08/my-new-portable-ide/
I’d like your opinion on my little article
”
3, Cursor just right to the starting bracket. CAPS and ALT and right, right, right. Good.*
4, Hit Delete
”
Just so you know, in JetBrains ides, these two steps would be a simple ‘cmd+w’ key struck. I like vim, but I believe that for most vim users I met, if they spend the same amount of time learning JetBrains ides as they did with vim, they could write develop faster.
For example, in your case, let’s say the cursor is in some other place of the file, here are the steps in vim,
1) hit ‘/’
2) type the parameter name (or partial)
3) hit enter
4) hit ‘n’ until the cursor gets to where the parameter is
5) hit ‘daw’
6) hit ‘i’
7) write the new parameter
8) hit ‘esc’
here are the steps in a JetBrains IDE
1) hit ‘cmd+f’
2) type the parameter name and in real time see all the hits highlighted on the editor
3) hit ‘F3’ until the cursor gets to where the parameter is
4) hit ‘cmd+w’
5) write the new parameter
I don’t really want to enter into the “vim vs IDEs” discussion, as I think is at least pointless. What I’m trying to explain is WHY Vim works and how is different from other forms of edit text.
Of course, there are lots of other valid options, and they also try to create shorcuts to common operations. They should be used more often, though, as, again, it’s difficult to learn all those small details that save us time…
Oh, and you can use ‘caw’ in your example to save you enter insert mode (or just cw if your search gets you at the start of the parameter) Vim should also highlight the search (if configured), and you can do Xn to go directly there (if counting is an option, usually I don’t bother) 😉
I’m not sure that vim step 3 really counts as a separate step.
Also, steps 5+6 should really be “hit ‘caw'”, because no-one does a delete and then goes into insert mode.
Lastly, the example picked is something that a JetBrains IDE can clearly do well. How would it deal with something a little more complicated like replacing the first two parameters to a function with one new parameter? (assuming there are a third, etc, parameters).
In vim, from a function call site, I would do something like:
1) hit gd to go to the (function) definition
2) ww to move inside the opening bracket
3) c2t, to change the text up to the second comma
4) type new parameter
5) hit jk (or ) to leave insert mode
For what it’s worth, I’ve had the Ctrl-W shortcut in SharpDevelop (I assume it works the same there) and it’s very nice to have in traditional IDEs, but less useful than a full vim…
Sorry, I’m not sure that I understood correctly your comment. Do you refer to the Vim step example or to the “others” step example? Steps 5 and 6 are only on the “others”.
Exactly this. There is no need to delete and go into insert mode in separate steps when you can simply ‘c’hange (which will delete and put you into insert mode automatically) the word, paragraph, or whatever you need, easily. Every Vim-user should start their day with a cup of coffee and reading :h motion.txt
Thanks for pointing out my mistake in vim step 5 and 6.
For your example, in JetBrains the steps are simliar
1) hit cmd+b to go to definition
2) hit alt+right twice to go inside the opening bracket
3) hit cmd+w twice to highlight all parameters in the bracket
4) type new parameters
I wasn’t talking about IDE vs vim either (nor was I trying to dimiss your logic on why vim is so great, it is!). I was just trying to point out that other editors (IDE included) is not that inferier compared to vim, it is just they take some learning curves too. BTW, there is an vim plugin (developed by JetBrains) for JetBrains IDEs, so it can have the power of both vim and IDEs.
Using vim without good personalized configuration and a few crucial plugins is pointless.
2) type the parameter name (or partial)
3) hit enter
4) hit ‘n’ until the cursor gets to where the parameter is
vs
1) hit ‘cmd+f’
2) type the parameter name and in real time see all the hits highlighted on the editor
With incsearch and hlsearch set up you have exact same thing. Just without annyoing windows and slowness of the IDE.
As I understand, cmd+w edits parameter? With proper text object you have the same, again without annoying popping windows: simply type cia(change-inside-argument).
Okay, so we start at random place of the page and we want to change parameter. Let’s say it looks like this:
| <———-cursor
//code code code
int asdf(int lorem, double ipsum);
//code
1) type /lorem Hit enter.
2) in case there is lorem repeated many times (realistically, with proper variable names it shouldn’t happen much)hit n until you get here
3) type cia
4) Write the new parameter type and name
5) hit key mapped to
About 5, I have it mapped to the capslock. Works great.
But it’s search-based paradigm. It could be better, for example with easymotion. I have mapped command that will ask for two chars and will get me in the place on the page where they reside. Probablity of many such places are quite small, but possible, in that case I addictionaly hit assigned key from home row. It’s mapped to lower-case s.
1) type sre (s is command that gets two chars)
2) In case of doubles hit the letter that appears at desired place, one of {j, f, d, k, s, l, a, ;}
3) type cia
4) write new parameter type and name
5) return to normal mode
Pingback: Vim’s killer feature | Evan Hahn
Link to Hacker News doesn’t work
Sorry, it it fixed now
as a vim USER, i have an idea for you to solve the problem easily:
1, made vim’s default mode to INSERT mode, so beginner could do what they want to do like in other editor, but when they want to improve themselves, they could easily hit the [ESC] to open the magic door
2, for begginer who might hit the [ESC] to make the mode changed, it need the editor to give a very extract notice to user, like giving a big cover layer which would mask all the editing area , in that case,
user could easily got to know they has made a big change and the editor area are really not editable .
i notice that many beginner would fear when they sometime hit [ESC] and found the editoring area didnt responsing their inputs,this might let them assem that they made a mistake which let the editor freeze.
I’m not sure. I think that an app should work for common use first. I’ll find very weird that it started in INSERT mode, as default mode, well, it’s the default. I don’t have really an answer about how to help beginners, but I don’t think that changing default behaviour is the way to go.
Pingback: Vim as IDE. Are you getting the wrong parts? | Wrong Side of Memphis
Pingback: Efficient Text Editing on MacOS | Alex Eberts
Pingback: Compendium of Wondrous Links vol V | Wrong Side of Memphis
Pingback: Vim – blogposts | Parobalth
If anyone is interested I released a book called Pro Vim last year: http://www.amazon.co.uk/Pro-Vim-Mark-McDonnell/dp/1484202511/ref=sr_1_1?ie=UTF8&qid=1417554324&sr=8-1&keywords=pro+Vim check it out regardless if you’re a beginner or long term user.
Thanks for the note, Mark!. Will take a look.
Pingback: VIM 的除了速度以外的優點 - Balicanta Yao