5 ms·

100 Vim commands every programmer should know

57 points by nickb 18y ago

0x44 18y ago
Zl snibevgr vf ttITt?
silentbicycle 18y ago
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.)
- matstc 18y ago
  > 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.
  - fallintothis 18y ago
    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...
    - joshuaxls 18y ago
      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.
- BrandonM 18y ago
  Note, though, that vim's . repeat operator doesn't see the macro as one unit, so to repeat it you have to specify quantity. True, but @@ repeats the last keyboard macro.
  - graywh 18y ago
    And @: repeats the last Ex command. And wow, this list of commands is awful. Just use "vimtutor" instead.
jamongkad 18y ago
This is nice and all but where are the commands for macros?
jdale27 18y ago
I hope that 100 is in base 2...
teedex 18y ago
Why should every programmer know these ? Sensationalistic blogging ?
undees 18y ago
The one I keep forgetting is ":q!" (really!). I think it's some kind of brain defect on my part.
- zenspider 18y ago
  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.
  - BrandonM 18y ago
    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).
    - zenspider 18y ago
      "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.
      - BrandonM 18y ago
        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.
Tichy 18y ago
I guess I am simply too lazy for Vim.
- BrandonM 18y ago
  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.)
  - Tichy 18y ago
    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.
    - BrandonM 18y ago
      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): * List item 1 * List item 2 * List item 3 * List item 4 We want to transform it to: <ul> <li>List item 1</li> <li>List item 2</li> <li>List item 3</li> <li>List item 4</li> </ul> (Let's ignore the fact that the trailing </li> is unnecessary.) Open up the initial file in vim, and press the following keys (note that <ESC> indicates the Escape key, but all other key presses are literal, including the two spaces before <li>): ggO<ul><ESC>qqj^2s <li><ESC>A</li><ESC>q3@qo</ul><ESC> gg - start from the top (not necessary if we're already there) 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).
blackman 18y ago
Isn't a patch on http://rayninfo.co.uk/vimtips.html 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??
davidw 18y ago
:q!
- dkasper 18y ago
  :q! heal wounds emacs &
st3fan 18y ago
And they say emacs is complex ...

57 points by nickb 18y ago

0x44 18y ago

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

matstc 18y ago
> 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.
- fallintothis 18y ago
  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...
  - joshuaxls 18y ago
    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.
BrandonM 18y ago
Note, though, that vim's . repeat operator doesn't see the macro as one unit, so to repeat it you have to specify quantity. True, but @@ repeats the last keyboard macro.
- graywh 18y ago
  And @: repeats the last Ex command. And wow, this list of commands is awful. Just use "vimtutor" instead.

jamongkad 18y ago

This is nice and all but where are the commands for macros?

jdale27 18y ago

I hope that 100 is in base 2...

teedex 18y ago

Why should every programmer know these ? Sensationalistic blogging ?

undees 18y ago

The one I keep forgetting is ":q!" (really!). I think it's some kind of brain defect on my part.

zenspider 18y ago
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.
- BrandonM 18y ago
  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).
  - zenspider 18y ago
    "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.
    - BrandonM 18y ago
      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.

Tichy 18y ago

I guess I am simply too lazy for Vim.

BrandonM 18y ago
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.)
- Tichy 18y ago
  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.
  - BrandonM 18y ago
    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): * List item 1 * List item 2 * List item 3 * List item 4 We want to transform it to: <ul> <li>List item 1</li> <li>List item 2</li> <li>List item 3</li> <li>List item 4</li> </ul> (Let's ignore the fact that the trailing </li> is unnecessary.) Open up the initial file in vim, and press the following keys (note that <ESC> indicates the Escape key, but all other key presses are literal, including the two spaces before <li>): ggO<ul><ESC>qqj^2s <li><ESC>A</li><ESC>q3@qo</ul><ESC> gg - start from the top (not necessary if we're already there) 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).

blackman 18y ago

Isn't a patch on http://rayninfo.co.uk/vimtips.html 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??

davidw 18y ago

:q!

dkasper 18y ago
:q! heal wounds emacs &

st3fan 18y ago

And they say emacs is complex ...