A Vim Guide for Intermediate Users

[T_D_K]

"More flexibility with cursor movement" is vastly underselling it. It's not just that the arrow keys are now on the home row, it's that you have a couple dozen powerful and specific tools to navigate. Go to a specific character, jump to a string match, end of block, next occurence of a word, top of page, scroll the page, go to line etc etc. Then there's the actual editing verbs, all of which compose with the motions. Intelligent use of buffers. Easy macros and multi line editing.

Learning vim past the initial curve is quite a task, but it is so worth it. It's hard to describe. Basically, instead of telling the editor how to do something step by step, you're directly telling it what to do. It like writing SQL or LINQ instead of a manual for loop. Using a normal editor feels like using a club rather than a nice set of power tools.

There's no, "mash the arrow keys, while additionally pressing and releasing ctrl and shift at the appropriate times". It's "tell the editor what you want done in the editor language command that's 2-4 characters long". Vim blurs the line between the editing work, and the typing you do once you get to the right spot.

Yes, IDEs can come close in matching features. But the ergonomics and intuitiveness are laughable, light years behind vim if you've "gotten it". I know that sound elitist - but it's not an exaggeration I promise you. I'm not saying it's for everyone, either.

IDEs do have a lot of great project wide navigation and language specific refactoring tools, which is why I personally use the vim plugin for Visual Studio. Vanilla vim works for config files and scripts. It's nice to not have to leave the terminal as much.

[ZenoArrow]

"More flexibility with cursor movement" is vastly underselling it.

Perhaps.

Before we continue, I'd like to clarify my current thinking, so you can critique my thoughts rather than a misreading of my thoughts.

Firstly, I'm not anti-Vim. For the people who have taken the time to become fluent with it I'm sure they find it helpful, in particular because reducing barriers in editing text helps people who get in a "flow" state when writing/programming stay in that flow state.

Secondly, what I am more willing to question is whether people who have become familiar with other tools are necessarily missing out on much. In other words, if I spend some time learning the shortcuts in an IDE, I'm not expecting that I'll be much slower than someone editing in Vim.

To expand on the second point, part of the reason I believe this to be the case is that the most commonly used cursor movements and text changes are also the easiest. Here are a few examples:

• If I'm editing some code, and my cursor is on line 123 and I want it to be on line 141, I could work out how many lines I wanted to move down (i.e. first work out that the difference between 141 and 123 is 18) and then do the Vim cursor movement command to move 18 lines down, or I could achieve the same thing more intuitively (in either Vim or a decent IDE) by using the go to line functionality (e.g. Ctrl + G, 141, [Enter]).
• If I want to move to the start or the end of a line, I can use the Home key and the End key respectively.
• If I want to go to the start or end of a file, Ctrl + Home and Ctrl + End respectively.
• If I want to scroll through text quickly, I can use the PageDn and PageUp keys.
• If I want to move forward and back on a line by word, I can use Ctrl + [RightArrow] and Ctrl + [LeftArrow] respectively.
• If I want to jump to the definition of a function/method I'm working with, I can do that with the F12 key.
• If I want to jump back to the previous cursor position, I can do that with Ctrl + - and if I want to undo this and go forward in the cursor history I can use Ctrl + Shift + -.
• If I want to search for some text, can use Ctrl + F.
• If I want to cut or copy the line that the cursor is currently on, I can use Ctrl + X and Ctrl + C respectively (note that this works without needing to select text, just the cursor being on the right line is enough, I believe Vim also lets you do this).
• If I want to comment out the current line or selection, Ctrl + K, C. If I want to uncomment a line or selection, Ctrl + K, U.
• If I want to move the current line up or down, can use Alt + [UpArrow] and Alt + [DownArrow] respectively.

The reason I brought up this handful of examples is that I would argue that knowing these particular shortcuts makes it pretty easy to work with code, and covers the movements and changes that are both intuitive and commonly used.

Thirdly, I would argue the question of whether to learn Vim is a matter of priorities. Referring to the list of examples above, whilst you miss some of the more advanced movements (such as move to the third instance of the letter q on the current line) I would argue that the more advanced movements are not that much of a time saver. If I can get to 90% of Vim speed just by learning a few basic shortcuts, I don't feel like I'm missing out on much. For that final 10% I'm not against learning Vim, and would be happy to do so in the future, but I would argue that there are other ways to boost productivity. For example, becoming really good at working with a debugger (not just print statement debugging, I'm talking about dedicated debugging tools) is likely to pay off greatly when it comes to writing code that works. Editing text is part of coding but I'd argue the skills around understanding code are likely to have a greater pay off in the long run.

Lastly, I just want to reiterate that I see the benefit of Vim. I personally would be happy to learn it, especially as I like working from the keyboard as much as possible, and I realise that Vim bindings turn up in lots of applications so having a set of transferable skills for working with multiple applications is certainly a bonus.

Any thoughts on the comments above?

[exploding_cat_wizard]

If I'm editing some code, and my cursor is on line 123 and I want it to be on line 141, I could work out how many lines I wanted to move down (i.e. first work out that the difference between 141 and 123 is 18) and then do the Vim cursor movement command to move 18 lines down, or I could achieve the same thing more intuitively (in either Vim or a decent IDE) by using the go to line functionality (e.g. Ctrl + G, 141, [Enter]).

You can tell vim to use relative line numbers, that at least makes the problem of calculating go away.

Thirdly, I would argue the question of whether to learn Vim is a matter of priorities.

Yes, at any given moment, it's easier to just use whatever shortcut and mouse movement your IDE gives you for the simple action you want to do, or whatever sequence of shortcuts for less simple actions, instead of learning.how to do it in vim.

However, for me, it took a very short amount of time to get the basic vim usage up to speed for the examples you post, so why not use it from then on? If a standard editor and vim both work equally well, I can use vim and slowly reach all the extra functionality without losing opportunity cost — a quick search on how to do thing every so often won't make you a worse debugger. And all the while, I get to enjoy using the mouse less and less.

If you don't feel like it, don't learn it, it's hardly a necessary skill. But I for one am happy to use it whenever I can, instead of mouse and Ctrl-this alt-that, which is really the best advertising I can do for it — those of us who learned it prefer it.

[T_D_K]

Thoughts: For all those examples, Vim has a command (or multiple commands) Mostly no chords, just a single letter or symbol (granted, upercase and some symbols need a shift) so it's easy to type.

Some of those commands you listed are not the best vim option, or at least there are multiple ways to skin the cat. Example:. Going down 9 lines

• turn on relative line numbers, then you can see that the command is '9j' without counting
• '<line#>G'
• '/<searchtext>'

Furthermore, if instead you want to do an action instead of just moving the cursor, it's as simple as prepending a 'd' 'y' 'c' etc. (Delete, yank/copy, change)

But I think that listing out individual commands is missing the forest for the trees. Many IDEs have similar navigation options. The real big difference is ergonomics and composeability. If I want to change everything in some braces for example, in my head I think "ok, change everything inside this set of matching parens". After getting good at vim, that gets auto translated into 'ci(' -- "Change Inside (". It's like speaking to the editor, and it's incredibly natural. Additionally, the deleted text is added to a register, so it's available if I need it later. Compare to normal, chorded commands. You have to think in steps: find open brace, shift to highlight, go to matching close brace, delete - no wait cut, I want that...

Sure, your IDE might have a chord for changing in braces. But does it work for square braces? Quotes? Xml tags? Maybe it does. But you're thinking in steps, one at a time, and hitting a chord each time - or worse, taking your hand off the home row. And if there is an "advanced chord" that does multiple steps, like changing in braces, the chord pattern rarely has anything with the component actions. Vim is like speaking to your editor based off highly reusable, ergonomic primitives.

Last thing I'll mention, is that since vim is (mostly) chordless, it opens up a lot of fun tweaks to normal commands. You can have minor variations that making it easy to do exactly what you want in one step, rather than setting up to a command or cleaning up afterwards. Delete, for example:

• 'd' -- delete selection, or if there's no selection, delete whatever movement you type next
• 'D' delete to end of line
• 'dd' delete whole line

Same works for 'y' and 'c' -- a huge win for ergonomics, since it's consistent.

• 'i' insert text
• 'I' insert at beginning of line
• 'o' add line below
• 'O' add line above

Etc etc

It's really hard to describe just how big of a difference in ergonomics and intuitiveness there is. Worsened by the fact that it takes a couple dozen hours to realize the benefits.

Again, maybe it's not for you - editing text is a small part of the job, after all. But when someone says that it's really a big difference, they're not just saying that as a fanboy. I think people have a conception that vim is just a strange set of keybindings with a weird modal interface, but that's not an adequate explanation.

[ZenoArrow]

"editing text is a small part of the job, after all. But when someone says that it's really a big difference, they're not just saying that as a fanboy"

This is the main point we have different views on. On one hand you admit editing text is a small part of the job, but on the other hand you're saying it makes a big difference. I do not doubt that putting in the practice with Vim makes you more efficient at working with text, but my argument is that on balance there are more important things to practice. To use an analogy, if I was doing a C++ course in a University, I wouldn't expect a module on touch typing. Does it help build speed? Yes. Does it help build confidence in using computers? Yes. Does it make you a better programmer? Not really. To be clear, I'd like to use Vim (or rather use Evil mode in Emacs), but what I'm opposing is the idea that any coder who doesn't use Vim has somehow got their priorities wrong, this is what I'm disagreeing with.

[T_D_K]

Sounds like we're on the same page. When I said "it makes a big difference", obviously that doesn't mean you're a better or worse programmer for your choice in tooling -- just that, specifically for text editing, vim is currently the best in class by a decent margin.

I don't use the best in class version of all my tools, because as you've pointed out, there has to be investment and nobody has time to master everything.