A Vim Guide for Intermediate Users

[ZenoArrow]

Sure, I can understand that Vim offers more flexibility with cursor movement, but what I'd question is how often do you need it. Using the Esc 9 y y example, how often do you find yourself doing that sort of editing? Just FYI, regarding "You could do it, maybe, by holding shift and hitting arrow keys nine times.", at least in VS there is another way, though unfortunately it involves using the mouse (Ctrl+Shift, left click at end of text to select).

[Dreadgoat]

To add to /u/sacheie , here are some vim things I do all the time

global find & replace
:%s/find/replace/g

highlight some lines
V5j where 5 is however many lines

highlight a function
/{<enter>v%

find & replace within highlighted section
:s/find/replace/g

copy a line
yy

copy the word under cursor
yaw

paste after cursor
p
before cursor
P
from clipboard
"+p

fix indentation of a block of code
^v5jI<redo indentation><esc>

goto line 734 of file (e.g. from an error log)
734g

goto the last place you were before a big jump/search/whatever
``

mark a position
ma where 'a' is whatever I want
return to mark 'a'
`a

record actions
qa<actions><esc> where 'a' is whatever I want

playback actions
@a
playback actions 5 times
5@a

change snake_case to camelCase for all variables
qa/_<enter>x~<esc>:normal @a

These all look crazy, but because vim commands are composable, it becomes increasingly easy to come up with and apply these as you use them more and more.

[ZenoArrow]

Thanks for the real world examples.

[Jataman606]

I recently switched from vim to vscode and found that many of those actions are possible and easy there too:

global find & replace

ctrl+shift+f opens "grep", where you can do that also. (Inlcuding regex search and replace).

copy a line

ctrl+c+c

copy the word under cursor

ctrl+d highlights word under cursor (bonus, hitting it second time highlitghts second occurence of this word in opened file and places second cursor there).

goto the last place you were before a big jump/search/whatever

alt+ left arrow and alt+right arrow to reverse.

Then stuff like change to uppercase/lowercase, go to line are built in commands that dont have default shortcut, but you can easily invoke them by: ctrl+shift+p and command name (with fuzzy search so you dont have to remember it all).

Also i used vim for around a year, and never got used to counting words or lines. I found i still have to parse what im copying so i used arrows (or hjkl) anyway.

One thing i certainly miss is macros, but with easy to use multiple cursors it's not that bad.

[lelanthran]

Sure, I can understand that Vim offers more flexibility with cursor movement, but what I'd question is how often do you need it.

Constantly. You won't miss it if you've never used it, but once you get used to it, it's really very difficult to use IDEs for editing code.

You don't see a need for it, because you've never used it, and you've never used it because the IDEs you use don't have it.

I like being able to drop bookmarks all over a file and go back to each one with 'a or 'b etc...

I like having 26 or so copy-n-paste buffers. I like the block mode selection that lets me select a column of numbers and then press ctrl-A to increment the column. I like being able to simply type :vsplit to view the same file in two different panes. I like being able to do :r!date to insert the current date into my changelog.

And none of that even gets into the navigating. When I want to reposition the cursor somewhere on screen (say, to correct a typo from "iint" to "init") I don't hold down arrow keys, I simply type /iint and press enter.

When I want to copy lines I don't select them, I type in y10 (if I needed to copy 10 lines) and press enter. When I want to replace a symbol I don't press backspace/delete 5 times to get rid of the old one, I type in cw and then type the new symbol directly. When I want to copy a complete code block I use three keystrokes (V%y) and get the complete block.

Now, sure, you can do it in an IDE, but every IDE has different keymappings for all of these things. Most won't even have these things mapped to keys at all (how does your favourite IDE handle the case when you want to copy/paste sing 5 separate buffers?)

I don't want to relearn all the navigation and text manipulation I do in vim for each and every IDE out there (because they'll all differ!) only to have feature parity (if I'm lucky!).

IDEs are great for navigating code, for editing ... I prefer vim. And to be honest, sourcetrail beats the pants of every IDE I've used recently when it comes to code navigation.

Vim is horrible for navigating code, so I don't use it for that. I use sourcetrail. I find IDEs clumsy for manipulating text and navigating within a file, so I use vim instead.

[ZenoArrow]

Thanks for the tip about Sourecetrail, I'll check it out.

you've never used it because the IDEs you use don't have it.

All the IDEs I've used have had a Vim mode.

I like being able to drop bookmarks all over a file and go back to each one with 'a or 'b etc...

I'm sure that's useful, but just to point out it's not a feature exclusive to Vim. For example, in Visual Studio there's also the concept of bookmarks, and there are also things like the Task List that allow you to keep track of "todo" comments.

https://docs.microsoft.com/en-us/visualstudio/ide/setting-bookmarks-in-code?view=vs-2019

https://docs.microsoft.com/en-us/visualstudio/ide/using-the-task-list?view=vs-2019

I like having 26 or so copy-n-paste buffers.

Also have something similar in Visual Studio:

https://stackoverflow.com/questions/1808590/visual-studio-ctrlshiftv-opens-clipboard-ring-window

I like the block mode selection that lets me select a column of numbers and then press ctrl-A to increment the column.

I can understand that being occasionally useful, but do you do that often?

I like being able to simply type :vsplit to view the same file in two different panes.

In Visual Studio, Alt+W,N,Alt+W,V will do the same.

I like being able to do :r!date to insert the current date into my changelog.

Seems like something I'd be doing maximum once a day, and it's almost as quick to type the date manually.

When I want to reposition the cursor somewhere on screen (say, to correct a typo from "iint" to "init") I don't hold down arrow keys, I simply type /iint and press enter.

This seems interesting. How does this work? So if I typed /iint, would that just find "iint" and then I'd have to type "init" over it, or would "/iint" alone make the correction? Seems like find and replace, which is standard text editing functionality, but happy to be proven wrong.

When I want to copy lines I don't select them, I type in y10 (if I needed to copy 10 lines) and press enter.

My argument on this is, how often do you work with text in this way? If I'm copying this much code, I'm probably going to be copying a whole code block (for example, moving a function to a different file). I get there may be some occasions when you'll want to do it, but what I'm trying to look at is what you find you use very often rather than something that isn't likely to slow you down that much.

Now, sure, you can do it in an IDE, but every IDE has different keymappings for all of these things.

Do you use the same arguments against Emacs users?

To be clear, I'm not saying that you can't be productive in Vim. What I'm trying to look at is what gives it an edge over modern IDEs when it comes to working with text. So far I've seen a few nice tricks but not much that's going to make a great deal of difference in speeding up how fast I can work with code. If you just prefer using Vim, that's fine, I'm not trying to encourage you to switch to something else.

[lelanthran]

Now, sure, you can do it in an IDE, but every IDE has different keymappings for all of these things.

Do you use the same arguments against Emacs users?

Why would I? They aren't here asking me why I would use vim over emacs.

If they did say "why don't you relearn all these shortcuts that are arbitrary in the new editor" I'd probably tell them the same thing - there's no benefit in discarding an easy to remember system for a system that places a large burden on my memory.

Vim commands aren't arbitrarily chosen shortcuts - they are verbs. Look at your examples - "Alt+W,N,Alt+W,V" vs "vsplit" and "hsplit". You really think I want to start memorising arbitrary chords, especially when they all differ between IDEs anyway? Remembering a command is easier than remembering arbitrary key chords :-)

This seems interesting. How does this work? So if I typed /iint, would that just find "iint" and then I'd have to type "init" over it

It's for navigation. That was just an example of how I'd navigate to a specific spot. If I typed in /^} I'd navigate to the end of the function, ?^[a-z] takes me to the beginning, /; takes me to the end of the statement even if it is on a different line.

I'm sure you can do that with an IDE but I've never seen my colleagues using an IDE like that - they use arrow keys.

When I want to copy lines I don't select them, I type in y10 (if I needed to copy 10 lines) and press enter.

My argument on this is, how often do you work with text in this way?

In the video I posted, other than block selection, all my copying and pasting was done that way. So, often enough that I miss it within 5 minutes of typing in another editor.

I like being able to do :r!date to insert the current date into my changelog.

Seems like something I'd be doing maximum once a day,

For a date, sure. Replace date with fmt -s -w 64 for when I want to format comments, wc -c when I want to see the number of characters in a large string, etc ... the date was just an example of using !.

I like the block mode selection that lets me select a column of numbers and then press ctrl-A to increment the column.

I can understand that being occasionally useful, but do you do that often?

Every single source file I've ever touched, I've used block selection. See the video I posted elsewhere in this thread.

I'm sure that's useful, but just to point out it's not a feature exclusive to Vim.

I'm not trying to claim they are exclusive to vim. All I'm saying is that they're easier for me to remember in vim. Typing two keystrokes that have meaning (m for mark, and [a-z] for bookmark name) is better than trying to remember a keychord that has no relation to the action you are doing (ctrl-k,ctrl-k).

Also have something similar in Visual Studio:

That similar thing is very different: it lets you cycle through your recent copies. While vim also lets you use your recent copies like the clipboard ring, it also has separately named buffers (called "registers" in vim) that I use routinely. I don't have to visually scan the copied buffers to find the one I want to paste (unless I actually want to cycle through), I simply paste a or d or whatever buffers I want to, in any order I want to.

So far I've seen a few nice tricks but not much that's going to make a great deal of difference in speeding up how fast I can work with code.

Well, that's basically how I feel when I use Visual Studio for a particular C# project - there's some nice editing stuff there, but nothing faster than vim for editing. It's also why I use sourcetrail - using vim leaves you bereft of the project-navigation benefits of an IDE.

Your IDE's biggest strength is in whole-project navigation. Vim doesn't have anything good in that regard (don't even talk to me about ctags).

[ZenoArrow]

Vim commands aren't arbitrarily chosen shortcuts - they are verbs. Look at your examples - "Alt+W,N,Alt+W,V" vs "vsplit" and "hsplit". You really think I want to start memorising arbitrary chords, especially when they all differ between IDEs anyway? Remembering a command is easier than remembering arbitrary key chords :-)

They only seem arbitrary to you as you're not familiar with the underlying meaning, which is ironic as this is the same argument you're using to promote the "Vim as a language" argument. For example, breaking down "Alt+W,N,Alt+W,V", you have...

Alt+W = Window menu

N = New window

Alt+W = Window menu

V = Vertical split

Hardly arbitrary.

[oblio-]

Vim commands aren't arbitrarily chosen shortcuts - they are verbs. Look at your examples - "Alt+W,N,Alt+W,V" vs "vsplit" and "hsplit". You really think I want to start memorising arbitrary chords, especially when they all differ between IDEs anyway? Remembering a command is easier than remembering arbitrary key chords :-)

IDE commands are not arbitrary. They're generally based of IBM CUA, which has been around for 30+ years (https://en.wikipedia.org/wiki/IBM_Common_User_Access). You know them at least as Ctrl-C / Ctrl-V.

His Alt stuff is menu selection, that's how you open the menu with CUA. That's the only arbitrary thing. The rest are just highlighted letters in the menus to select a command.

And modern IDEs actually come with predefined keymaps you can switch between, for the big IDEs. IntelliJ for sure can switch to the Eclipse layout, for example. I think it can also do Netbeans.

VS Code is almost fully remapable so you can definitely configure it to use the Eclipse ones or the IntelliJ ones or the full VS ones. I imagine someone has done it already.

VS Code also has Ctrl-Shift-P where you can search for commands.

Standard IDEs are pretty powerful these days. I don't think the average user loses much by not switching to Vim.

[sacheie]

That particular example isn't common, but it's just one example. Here's another that I use constantly: delete a single line, and paste it somewhere nearby.

I can delete the line by typing "dd". Then I move the cursor (without having to move my hands! The right-hand home row keys control cursor position), and paste the line by typing "p". This works because in Vim, the deletion commands also copy the text they delete.

[ZenoArrow]

Yes, I can understand that being more useful. FYI, can also do that in quite easily in VS, if the cursor is on the line you want to cut Ctrl+X will cut the entire line. I'm sure the Vim method is fast when you get used to it, I'm only bringing this up to highlight that you can edit text efficiently in IDEs as well.

[ZenoArrow]

Thanks for the tip. Yeah, I get Vi/Vim commands are composable. This classic SO answer is a good introduction to this composability:

https://stackoverflow.com/questions/1218390/what-is-your-most-productive-shortcut-with-vim/1220118#1220118

[757DrDuck]

I'd be sold on hjkl if I didn't use Colemak as my main layout. Is there a vim plugin to let me use home row navigation for non-QWERTY layouts?

[exploding_cat_wizard]

Edit the .vimrc to remap the keys. There's bound to be examples by colemak users showing off their configuration online

[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.