100 Vim commands every programmer should know(catswhocode.com)
catswhocode.com
100 Vim commands every programmer should know
http://www.catswhocode.com/blog/web-development/100-vim-commands-every-programmer-should-know-11
33 comments
Zl snibevgr vf ttITt?
I'm shocked that this doesn't cover keyboard macro recording.
If you press q and then some letter, then do something, and press q again, it will record that as an action. For instance, qadWElpbq ("Start recording this in register a: cut next word, move to end of next word, forward char, paste, backward to beginning of that word. Done recording.". Basically, move the word under the cursor ahead one word.) under a (the qa) at the beginning, and then to repeat it you can just type @a. This is frequently straightforward for things that would be awkward with regex find-and-replace.
This works with the numeric prefixes, too; you could then type 10@a to shift a word ahead ten words, or double-space the next 200 lines, or what have you. Note, though, that vim's . repeat operator doesn't see the macro as one unit, so to repeat it you have to specify quantity.
Once your fingers learn this, you will use it all the time.
You can do this in basic vi, but as far as I know you have to manually stuff the macro into the character register* by writing it out and deleting it into a register, e.g. "ad$ (that's "a for into-register a, d$ for delete-to end-of-line). This feels more awkward than just hitting q (register) to start recording, but it's still useful. (* In BSD's nvi, at least.)
(The same thing in Emacs is C-x ( to start recording, C-x ) to stop recording, and C-x e to execute the last macro. There are commands to name and save your keyboard macros in a more permanent fashion, but I don't remember what they're called. Anything that isn't a throwaway macro I tend to just write in elisp anyway.)
If you press q and then some letter, then do something, and press q again, it will record that as an action. For instance, qadWElpbq ("Start recording this in register a: cut next word, move to end of next word, forward char, paste, backward to beginning of that word. Done recording.". Basically, move the word under the cursor ahead one word.) under a (the qa) at the beginning, and then to repeat it you can just type @a. This is frequently straightforward for things that would be awkward with regex find-and-replace.
This works with the numeric prefixes, too; you could then type 10@a to shift a word ahead ten words, or double-space the next 200 lines, or what have you. Note, though, that vim's . repeat operator doesn't see the macro as one unit, so to repeat it you have to specify quantity.
Once your fingers learn this, you will use it all the time.
You can do this in basic vi, but as far as I know you have to manually stuff the macro into the character register* by writing it out and deleting it into a register, e.g. "ad$ (that's "a for into-register a, d$ for delete-to end-of-line). This feels more awkward than just hitting q (register) to start recording, but it's still useful. (* In BSD's nvi, at least.)
(The same thing in Emacs is C-x ( to start recording, C-x ) to stop recording, and C-x e to execute the last macro. There are commands to name and save your keyboard macros in a more permanent fashion, but I don't remember what they're called. Anything that isn't a throwaway macro I tend to just write in elisp anyway.)
> I'm shocked that this doesn't contain keyboard macro recording.
Yes. And maps (e.g. :map <F12> :w<cr> to save with F12). And block mode (Ctrl-V) and text objects (e.g. ci" deletes the inside of parentheses and goes to insert mode) and a slew of others.
I find the idea that there are 100 vim commands every programmer should know a but ludicrous though.
Yes. And maps (e.g. :map <F12> :w<cr> to save with F12). And block mode (Ctrl-V) and text objects (e.g. ci" deletes the inside of parentheses and goes to insert mode) and a slew of others.
I find the idea that there are 100 vim commands every programmer should know a but ludicrous though.
ci" deletes the inside of parentheses
I think you mean inside quotes, by the way.
I find the idea that there are 100 vim commands every programmer should know a but ludicrous though.
Especially considering that the "100" commands were all compositions of simpler vim commands anyways. I don't think this is actually that great a submission, for this reason. How many ways are there to rehash some really specific example -- say, counting both ":set syntax [on|off]"? Vim is so much more general than that. It seems inaccurate -- even discourteous -- to treat this as some laundry list of commands in your bag of tricks (except in the case of, say, muscle memory). From my experience, you don't memorize some long string of letters as a command; you think of what each tiny bit does in and of itself, then compose that into whatever you want to accomplish. Rather than commit the string "ggguG" to your brain, vim users think of it as "go to the beginning of the file (gg), then uppercase (gu) to the end of the the file (G)". Granted, vim gets more complicated as you delve into the realm of motions, .vimrc level configurations, ex command line, etc.
Also, it seems that vim users would be the real ones who need to know such things, not every programmer altogether. The title feels cheap / sensationalized that way.
If there were some REAL list of vim commands "every programmer should know" (well, vim-user), I'd at least start by recommending the alphabet...
I think you mean inside quotes, by the way.
I find the idea that there are 100 vim commands every programmer should know a but ludicrous though.
Especially considering that the "100" commands were all compositions of simpler vim commands anyways. I don't think this is actually that great a submission, for this reason. How many ways are there to rehash some really specific example -- say, counting both ":set syntax [on|off]"? Vim is so much more general than that. It seems inaccurate -- even discourteous -- to treat this as some laundry list of commands in your bag of tricks (except in the case of, say, muscle memory). From my experience, you don't memorize some long string of letters as a command; you think of what each tiny bit does in and of itself, then compose that into whatever you want to accomplish. Rather than commit the string "ggguG" to your brain, vim users think of it as "go to the beginning of the file (gg), then uppercase (gu) to the end of the the file (G)". Granted, vim gets more complicated as you delve into the realm of motions, .vimrc level configurations, ex command line, etc.
Also, it seems that vim users would be the real ones who need to know such things, not every programmer altogether. The title feels cheap / sensationalized that way.
If there were some REAL list of vim commands "every programmer should know" (well, vim-user), I'd at least start by recommending the alphabet...
I agree wholeheartedly with pretty much everything you've said here. There is no magic "Vim cheat sheet" for new Vim users. To understand the power of Vim, you have to understand the power of its parts. It reminds me of playing with K'NEX as a kid: you either learn how to build magnificent things by learning how pieces combine to form powerful designs, or you blindly follow the built-in diagrams for prefabricated creations (not really understanding how they came to be) and then dump it a few days later out of boredom.
That said, I up-voted this submission solely because it's showing off Vim. That's what I try to do with the programmers I meet -- evangelize about Vim.
I'll never forget the first time I saw an ancient Vim user hacking away at code. It seriously blew me away, and I knew that I had to learn it. Via a combination of :help and O'Reilly's "Learning the Vi Editor", I learned. Four years later (and that's young for a Vim user), I'll never look back.
Point being: you can't learn via a cheat sheet. Dive into Vim, starting from the basics.
That said, I up-voted this submission solely because it's showing off Vim. That's what I try to do with the programmers I meet -- evangelize about Vim.
I'll never forget the first time I saw an ancient Vim user hacking away at code. It seriously blew me away, and I knew that I had to learn it. Via a combination of :help and O'Reilly's "Learning the Vi Editor", I learned. Four years later (and that's young for a Vim user), I'll never look back.
Point being: you can't learn via a cheat sheet. Dive into Vim, starting from the basics.
Well, I found the list to be very useful. I did not know about "/jo[ha]n", for example.
That's basic regular expression syntax. Learning that will go a long way in helping you learn a lot of tools in Unix, including grep, sed, vim, emacs, perl (which generally has a slightly different syntax, but one that matches in this case), bash programming in general, and more.
I frequently use:
set pastetoggle=<F11>
This toggles paste mode which allows you to paste without indention getting screwed up.
set pastetoggle=<F11>
This toggles paste mode which allows you to paste without indention getting screwed up.
This is nice and all but where are the commands for macros?
I hope that 100 is in base 2...
Why should every programmer know these ? Sensationalistic blogging ?
The one I keep forgetting is ":q!" (really!). I think it's some kind of brain defect on my part.
as an emacs user, that's the only one I'm required to know. :)
Actually I'm competent in vi, so I can pair with others, but man I don't like it.
Actually I'm competent in vi, so I can pair with others, but man I don't like it.
I started off using Xemacs during my undergrad, but I never really learned how to use it efficiently. When I later returned to Unix, I picked up vim and started using it for everything. When I later returned to emacs, even having learned some keybindings (thanks to GNU readline in gnome-terminal), I just felt handcuffed in my movement abilities.
The thing that makes vim great is the many (confusing for initial users, perhaps) different ways of moving around in the file, entering Insert mode, etc. Once you get the hang of that, you'll find yourself cursing any editor that doesn't have an easy way to move to the end of the 3rd word from the current location.
That said, I think I'll eventually find myself using emacs in viper-mode, especially if I ever get around to migrating to Lisp (from mainly Python).
The thing that makes vim great is the many (confusing for initial users, perhaps) different ways of moving around in the file, entering Insert mode, etc. Once you get the hang of that, you'll find yourself cursing any editor that doesn't have an easy way to move to the end of the 3rd word from the current location.
That said, I think I'll eventually find myself using emacs in viper-mode, especially if I ever get around to migrating to Lisp (from mainly Python).
"Once you get the hang of that, you'll find yourself cursing any editor that doesn't have an easy way to move to the end of the 3rd word from the current location."
I find myself cursing any editor that is moded. Moded editing is simply wrong. That said, I doubt there is any movement command in vi that is missing from emacs. The editors are the same in basic text-editing functionality. They differ drastically in philosophy and extended functionality.
I find myself cursing any editor that is moded. Moded editing is simply wrong. That said, I doubt there is any movement command in vi that is missing from emacs. The editors are the same in basic text-editing functionality. They differ drastically in philosophy and extended functionality.
Ok... well here is something that especially bothers me when working at my shell prompt. In vim, I press W to skip to the first character of the next word, where the only word delimiter is whitespace. In emacs, M-f moves forward to the next word, but any punctuation (including underscores, strangely) is considered to be a separator. So how do I perform this movement in emacs?
In vim, I press l to move to the right one character. In emacs, it's C-f or I have to reach for the right arrow. Do you really think the movement commands in emacs are just as convenient as vim?
I think moded editors mirror the desired functionality perfectly. In some cases, I just want to be typing a lot of stuff, and when I'm doing that, I'm in Insert mode. In other cases, I want to move around the file and make various minor edits, and for this I'm in Normal mode. How is that "simply wrong"? It's basically similar to when a user of a point-and-click IDE would switch from typing stuff to pointing-and-clicking on stuff.
In vim, I press l to move to the right one character. In emacs, it's C-f or I have to reach for the right arrow. Do you really think the movement commands in emacs are just as convenient as vim?
I think moded editors mirror the desired functionality perfectly. In some cases, I just want to be typing a lot of stuff, and when I'm doing that, I'm in Insert mode. In other cases, I want to move around the file and make various minor edits, and for this I'm in Normal mode. How is that "simply wrong"? It's basically similar to when a user of a point-and-click IDE would switch from typing stuff to pointing-and-clicking on stuff.
I guess I am simply too lazy for Vim.
So because you're lazy, you'd rather use more keystrokes to accomplish the same task? (I voted you up because I didn't see any need for you to get -1 karma for that comment.)
Not sure, many of the tasks never really seem to come up. When I used emacs, I used the macro recording facility a lot, for example to change larger chunks of code.
Eventually I had to switch to Eclipse, and didn't really need the Macros anymore, because of the refactoring functionality that comes with Eclipse. For example, in Emacs I used a macro to quickly generate getters and setters for my class variables (Java - I know...). Eclipse has a Source->Generate Getters and Setters Menu item, so I don't need to fumble around with Macros anymore.
Not saying that Eclipse is better, but I simply don't seem to be the kind of person who can remember 100 key combinations. I couldn't for emacs, either, even though sometimes I tried to learn new Emacs tricks.
I didn't learn that many keyboard shortcuts for Eclipse, either, even though I keep telling myself that I should. But I can only remember the most important ones, and I learn them because the menu items display a keyboard shortcut.
By the way, I seem to remember a quote by some Apple employee who said that in experiments using the GUI was actually faster than keyboard shortcuts. Keyboard shortcut people thought they were faster, but they weren't. Not sure if it is true - hard to believe, but still.
Eventually I had to switch to Eclipse, and didn't really need the Macros anymore, because of the refactoring functionality that comes with Eclipse. For example, in Emacs I used a macro to quickly generate getters and setters for my class variables (Java - I know...). Eclipse has a Source->Generate Getters and Setters Menu item, so I don't need to fumble around with Macros anymore.
Not saying that Eclipse is better, but I simply don't seem to be the kind of person who can remember 100 key combinations. I couldn't for emacs, either, even though sometimes I tried to learn new Emacs tricks.
I didn't learn that many keyboard shortcuts for Eclipse, either, even though I keep telling myself that I should. But I can only remember the most important ones, and I learn them because the menu items display a keyboard shortcut.
By the way, I seem to remember a quote by some Apple employee who said that in experiments using the GUI was actually faster than keyboard shortcuts. Keyboard shortcut people thought they were faster, but they weren't. Not sure if it is true - hard to believe, but still.
I want to first state for the record that my above comment was intended as a joke (I should have winked), but I think you knew that.
That said, the beauty of vim (and I'm assuming emacs as well) is that with the macro facilities, you are basically writing small programs to manipulate your source code, interactively. Let's say I want to convert some markdown into HTML using vim. Let's create the following source code (using whatever method you want):
O - enter a new line above current line and enter Insert mode
<ul><ESC> - enter some text
qq - begin recording all keystrokes into register "q" (here is the "writing small program" part that I mentioned)
j^ - move down and to the beginning of the next line
2s - erase two characters, entering insert mode
<SPACE><SPACE><li><ESC> - enter some more text
A - move to the end of the current line and enter insert mode
</li><ESC> - enter some more text
q - stop recording
3@q - perform the keystrokes recorded in register "q" 3 times (run our "small program" 3 times). This step always makes me smile, because seeing such complex changes to a large piece of code with just a few keystrokes seems almost magical
o - enter Insert mode after the current (last) line
</ul><ESC> - enter some more text. Note: you may need to press Ctrl-d before typing </ul> if you have autoindent turned on, in order to decrease the indent
Task completed. That is a somewhat trivial example, but it's a small taste of something that no editor without keyboard macros -- and the power to control everything with keystrokes -- could ever accomplish.
It also showcases 4 different methods (O, s, A, o) for entering Insert mode (none of them being the typical i), all of them useful in their own right. These are the types of things I miss when using emacs (without viper-mode).
That said, the beauty of vim (and I'm assuming emacs as well) is that with the macro facilities, you are basically writing small programs to manipulate your source code, interactively. Let's say I want to convert some markdown into HTML using vim. Let's create the following source code (using whatever method you want):
* List item 1
* List item 2
* List item 3
* List item 4
<ul>
<li>List item 1</li>
<li>List item 2</li>
<li>List item 3</li>
<li>List item 4</li>
</ul>
ggO<ul><ESC>qqj^2s <li><ESC>A</li><ESC>q3@qo</ul><ESC>
O - enter a new line above current line and enter Insert mode
<ul><ESC> - enter some text
qq - begin recording all keystrokes into register "q" (here is the "writing small program" part that I mentioned)
j^ - move down and to the beginning of the next line
2s - erase two characters, entering insert mode
<SPACE><SPACE><li><ESC> - enter some more text
A - move to the end of the current line and enter insert mode
</li><ESC> - enter some more text
q - stop recording
3@q - perform the keystrokes recorded in register "q" 3 times (run our "small program" 3 times). This step always makes me smile, because seeing such complex changes to a large piece of code with just a few keystrokes seems almost magical
o - enter Insert mode after the current (last) line
</ul><ESC> - enter some more text. Note: you may need to press Ctrl-d before typing </ul> if you have autoindent turned on, in order to decrease the indent
Task completed. That is a somewhat trivial example, but it's a small taste of something that no editor without keyboard macros -- and the power to control everything with keystrokes -- could ever accomplish.
It also showcases 4 different methods (O, s, A, o) for entering Insert mode (none of them being the typical i), all of them useful in their own right. These are the types of things I miss when using emacs (without viper-mode).
I didn't follow your example exactly, but I think it is similar to what I'd do with Emacs macros. I would record things like "move cursor to end of word", "skip two words", "capitalize word" and so on, which were all available as keyboard shortcuts, and then just press "repeat macro five times", done.
I enjoyed working like that, also because one feels rather clever doing such things, but as I said, it didn't come up that much anymore with Eclipse. I am also not sure if I was really that much faster, because I often had to look up stuff like how to skip a word and so on.
However, I am very curious about vim and Emacs, as I am currently considering to switch back. Mostly I would really like an editor that allows me to extend it myself quickly. One can write Eclipse plugins, but I don't know how complicated it is. Maybe not that complicated - but it certainly would have to be in Java, which I'd like to get away from.
Probably I'll switch back to Emacs, as I already know it a little bit. I am worried that Emacs LISP is too messy to be worthwhile to learn, though (I am more of a Scheme person, I guess).
I never knew Vim was so extendible, it certainly sounds very interesting. I am not much of a Unix shell wizard, though - although I wouldn't mind becoming better at that, either (I've read that extending Vim draws on shell commands?).
Btw., what made me switch to Eclipse was a project that Emacs couldn't handle. It was J2ME programming, and back then as much code as possible had to go into one file. So I had a 10000 lines code file, and Emacs would just crash or not do much. It was also impossible to navigate without the "abstract code view" (which let's you click on methods and jump to their position in the code). My colleagues were using Eclipse and laughing about me... There are other niceties about Eclipse, like the local history or good svn integration.
It certainly seems a bit of a drag to set up Emacs for coding again (Ruby on Rails would be my next target). It can do a lot of things, like jumping to code snippets and so on, but first you have to set it up, somehow. As I said, I am lazy, I'd rather have an Editor or IDE that is configured properly out of the box.
I wasn't so impressed with Netbeans for RoR, though. Didn't look at it for long, but it didn't even help you fill in the parameters for the code generators - it merely provided some buttons to run them. If I could extend my editor easily, I would make something better (hopefully I will).
I enjoyed working like that, also because one feels rather clever doing such things, but as I said, it didn't come up that much anymore with Eclipse. I am also not sure if I was really that much faster, because I often had to look up stuff like how to skip a word and so on.
However, I am very curious about vim and Emacs, as I am currently considering to switch back. Mostly I would really like an editor that allows me to extend it myself quickly. One can write Eclipse plugins, but I don't know how complicated it is. Maybe not that complicated - but it certainly would have to be in Java, which I'd like to get away from.
Probably I'll switch back to Emacs, as I already know it a little bit. I am worried that Emacs LISP is too messy to be worthwhile to learn, though (I am more of a Scheme person, I guess).
I never knew Vim was so extendible, it certainly sounds very interesting. I am not much of a Unix shell wizard, though - although I wouldn't mind becoming better at that, either (I've read that extending Vim draws on shell commands?).
Btw., what made me switch to Eclipse was a project that Emacs couldn't handle. It was J2ME programming, and back then as much code as possible had to go into one file. So I had a 10000 lines code file, and Emacs would just crash or not do much. It was also impossible to navigate without the "abstract code view" (which let's you click on methods and jump to their position in the code). My colleagues were using Eclipse and laughing about me... There are other niceties about Eclipse, like the local history or good svn integration.
It certainly seems a bit of a drag to set up Emacs for coding again (Ruby on Rails would be my next target). It can do a lot of things, like jumping to code snippets and so on, but first you have to set it up, somehow. As I said, I am lazy, I'd rather have an Editor or IDE that is configured properly out of the box.
I wasn't so impressed with Netbeans for RoR, though. Didn't look at it for long, but it didn't even help you fill in the parameters for the code generators - it merely provided some buttons to run them. If I could extend my editor easily, I would make something better (hopefully I will).
So I had a 10000 lines code file, and Emacs would just crash or not do much.
That's suprising. What version of Emacs was this and what kind of machine did you have? How did you configure it? Anything capable of running Eclipse should have no problem running Emacs. And as far as clicking on methods and jumping to places in the code goes, Emacs+etags (and M-x visit-tags-table) have been doing that pretty well for the past 15 years.
That's suprising. What version of Emacs was this and what kind of machine did you have? How did you configure it? Anything capable of running Eclipse should have no problem running Emacs. And as far as clicking on methods and jumping to places in the code goes, Emacs+etags (and M-x visit-tags-table) have been doing that pretty well for the past 15 years.
It was maybe 5 years ago, and I was probably running that Java IDE "plugin" for Emacs, too. Might have been version 18.x, and a computer with 600MhZ CPU, 256MB RAM.
I know about etags, but that is just the thing: you have to set it up and run it regularly. Also, it did not work as well as an IDE that really understands the code (etags don't understand the code). At least that was my impression - my "jumps" in Emacs would frequently lead to the wrong place.
Edit: also, what I meant for navigation was the code outline. In an IDE, you get an extra window listing only the methods you defined in your code. You can click on a method and jump right to the code. The IDE thing for emacs did that, too, but not as nicely (it was in a weird sidebar without proper scrollbars, for one thing).
That is also a Java sickness of course, that there are zillions of interfaces and abstract classes with the same name (BlubInterface, AbstractBlubBase, BlubImpl). But Eclipse then gives you a popup where you can select the proper class (showing the classes hierarchically).
I know about etags, but that is just the thing: you have to set it up and run it regularly. Also, it did not work as well as an IDE that really understands the code (etags don't understand the code). At least that was my impression - my "jumps" in Emacs would frequently lead to the wrong place.
Edit: also, what I meant for navigation was the code outline. In an IDE, you get an extra window listing only the methods you defined in your code. You can click on a method and jump right to the code. The IDE thing for emacs did that, too, but not as nicely (it was in a weird sidebar without proper scrollbars, for one thing).
That is also a Java sickness of course, that there are zillions of interfaces and abstract classes with the same name (BlubInterface, AbstractBlubBase, BlubImpl). But Eclipse then gives you a popup where you can select the proper class (showing the classes hierarchically).
I am also not sure if I was really that much faster, because I often had to look up stuff like how to skip a word and so on.
But that is the reason that I love it in vim. Because of the lack of mouse support and the powerful ways to move around in Normal mode, learning the different movement commands is a must. Then, when you go to build macros, you're using the same commands you always do.
But that is the reason that I love it in vim. Because of the lack of mouse support and the powerful ways to move around in Normal mode, learning the different movement commands is a must. Then, when you go to build macros, you're using the same commands you always do.
How long do you reckon would it take learn the commands? I wouldn't mind being good at that...
Edit: I am suddenly intrigued to learn Vim. Is there a mode for editing MZScheme? Or what is the best way to program MZScheme with Vim? Ruby on Rails would also be of interest. JavaScript?
Edit: I am suddenly intrigued to learn Vim. Is there a mode for editing MZScheme? Or what is the best way to program MZScheme with Vim? Ruby on Rails would also be of interest. JavaScript?
I'm still learning more commands, actually. h j k l w b { and } are some good ones to start with, and then once you find yourself using those all the time, you can pull out a vim cheat sheat and learn some more, like e ( ) # and *, and so on...
I have not yet found a language that doesn't have a vim mode, at least in my Gentoo installation. This includes HTML, CSS, Lisp, C, Python, Xorg.conf, various Gentoo system files, httpd.conf, and anything else I've seen.
I have not yet found a language that doesn't have a vim mode, at least in my Gentoo installation. This includes HTML, CSS, Lisp, C, Python, Xorg.conf, various Gentoo system files, httpd.conf, and anything else I've seen.
Btw., I just checked how to do your transformation in Eclipse, using regular expressions. ctrl+f pops up the finder window. Check "regular expressions". Then in "find" enter ".* (\w+ \w+ \d)" and in "Replace With" enter "<li>$1</li>". Press "replace all".
This gives you the <li>...</li> bits - add <ul> and </ul> by hand as you have to do in Vim.
The impressive thing is that the finder popup also includes context sensitive help for regular expressions. So If you type \, it gives you a list with all the options (\w for word character, \d for digit, and so on).
I am fairly good with regular expressions, not so much with keyboard shortcuts. Combined with the context sensitive help, the regular expressions are even more powerful.
I think Emacs also has regular expression search and replace, but without the context sensitive help.
This gives you the <li>...</li> bits - add <ul> and </ul> by hand as you have to do in Vim.
The impressive thing is that the finder popup also includes context sensitive help for regular expressions. So If you type \, it gives you a list with all the options (\w for word character, \d for digit, and so on).
I am fairly good with regular expressions, not so much with keyboard shortcuts. Combined with the context sensitive help, the regular expressions are even more powerful.
I think Emacs also has regular expression search and replace, but without the context sensitive help.
Isn't a patch on http://rayninfo.co.uk/vimtips.html. Looks like most of it has been taken from here anyway. Is it really necessary for a programmer to rot13 his code??
And they say emacs is complex ...