Vim Cheat Sheet - For Programmers By Programmers(michael.peopleofhonoronly.com)
michael.peopleofhonoronly.com
Vim Cheat Sheet - For Programmers By Programmers
http://michael.peopleofhonoronly.com/vim/
18 comments
Vi is like touch typing or driving a stick shift, it needs to be muscle memory to get full benefit from it, but it takes a while to learn and a long time to really sink in. Learning touch typing was worth the effort for me; I'm not sure at this point if all the time I spend 'learning' (i.e, mucking about with) Vi will be worth it purely in time saved. However I do love the ease and speed with which I can edit now, so for the comfort of editing, and for me, it was worth it, I think.
Touch typing is a great analogy. I was a pretty good hunt-and-peck typer in 6th grade; I would even do 2-3 finger "rolls" across keys to type faster.
Learning to touch-type was frustrating at first: I knew I could go faster with my usual methods. But with perseverance, I became much faster with touch typing than I ever was before.
Vim is the same way. At first, it feels terrible to have to use these awkward keystrokes instead of the GUI editor commands you're used to. But eventually, with muscle memory and intentional practice, editing in Vim becomes very fast and efficient.
Learning to touch-type was frustrating at first: I knew I could go faster with my usual methods. But with perseverance, I became much faster with touch typing than I ever was before.
Vim is the same way. At first, it feels terrible to have to use these awkward keystrokes instead of the GUI editor commands you're used to. But eventually, with muscle memory and intentional practice, editing in Vim becomes very fast and efficient.
I recently written this introduction:
http://goo.gl/oRn1K
It received quite a lot of positive returns.
But the idea behind vim is you don't learn vim like you learn a lesson. You learn vim like you learn piano. You have to use it against your intuition for some days until you're accustomed to it. Once done, you'll start to progress by adding a new habit regularly.
The most difficult part is to start and continue until you reach a standard usability zone. After each new trick will make you better, stronger, faster.
http://goo.gl/oRn1K
It received quite a lot of positive returns.
But the idea behind vim is you don't learn vim like you learn a lesson. You learn vim like you learn piano. You have to use it against your intuition for some days until you're accustomed to it. Once done, you'll start to progress by adding a new habit regularly.
The most difficult part is to start and continue until you reach a standard usability zone. After each new trick will make you better, stronger, faster.
vim will auto complete words if you press control-p while in insert mode.
http://i.imgur.com/tdcEc.png
For what it's worth I feel how you feel about vim, about emacs. I suspect it's just a matter of familiarity.
edit: As DrJ points out, control-n works too. Seems the 'p' is for previous keyword and the 'n' for next keyword.
http://i.imgur.com/tdcEc.png
For what it's worth I feel how you feel about vim, about emacs. I suspect it's just a matter of familiarity.
edit: As DrJ points out, control-n works too. Seems the 'p' is for previous keyword and the 'n' for next keyword.
The "M-x <tab>" that kamaal is talking about is for editor commands. Similar to ": <tab>" in Vim. The difference being that all of Emacs' editor commands (even "move one char to the left") are elisp functions that are available from the M-x prompt.
I agree that this is way too much information to be useful. I like focused cheatsheets that help you on a particular aspect that you're trying to improve. I created a cheatsheet for the most important vim movement commands that helped me focus to memorize all of them rather than get overwhelmed (http://naleid.com/blog/2010/10/04/vim-movement-shortcuts-wal...).
Personally I found vim easier to memorize than emacs commands and that's one of the reasons I went with it. If you work in vim day in and day out for a year (with a little curiosity and exploration) you should have most of this cheat sheet committed to muscle memory and move on to formulating more complex macros and using more advanced vim plugins to their potential.
I agree that emacs is more elegant in its implementation, but then again I think the very foundation of building an editor in lisp creates a level of elegance that is almost impossible to reach by any other path. In other words, vim is less elegant, but I don't think it's bad.
Fundamentally I see vim/emacs as unequaled peers. Vim is optimized for raw text editing potential, and emacs is optimized for customizability. Vim is still richly extensible, and emacs is still powerful for raw editing out of the box, but they lose out to each other on their respective strengths. I think the vim expert will be more effective editing disparate files on vanilla systems, and the emacs user will be more effective customizing his environment for his particular workflows.
I agree that emacs is more elegant in its implementation, but then again I think the very foundation of building an editor in lisp creates a level of elegance that is almost impossible to reach by any other path. In other words, vim is less elegant, but I don't think it's bad.
Fundamentally I see vim/emacs as unequaled peers. Vim is optimized for raw text editing potential, and emacs is optimized for customizability. Vim is still richly extensible, and emacs is still powerful for raw editing out of the box, but they lose out to each other on their respective strengths. I think the vim expert will be more effective editing disparate files on vanilla systems, and the emacs user will be more effective customizing his environment for his particular workflows.
There is the auto/omni-complete functionality using C-n
"wollw" and "DrJ" I am talking about command auto completion, not word auto completion inside the editor.
In emacs, for word auto completion M-/ is just too awesome.
In emacs, for word auto completion M-/ is just too awesome.
Pressing Tab completes commands in command-line mode, and its very smart. (Be sure to :set wildmenu to see a list of all matching commands as well.)
Even without wildmenu option, repeatedly pressing TAB key will cycle through the list of matches.
What's more, you can press <ctrl-D> to view the whole list of possible completions at one time. For example, enter ':colo ' then press <ctrl-D> and you'll see a list of all the colorscheme names. (The space in ':colo ' is important, since if you press ctl-D with just ':colo' Vim will just show you the 'colorscheme' completion. . . )
You can press the tab key in Vim to get command auto completion.
For example, :colo<tab> completes to :colorscheme.
For example, :colo<tab> completes to :colorscheme.
Command-line mode has tab completion. I'm not aware of there being auto completion in the other modes.
This is why I only use the most basic features of vim. There are simply too many commands to learn and many of these tutorial and cheatsheets present you with too much information. I don't think the time investment makes sense, and I don't understand why there has to be so much noise: how many of those commands save a significant amount of time; how often are they used?
The questions I would like to ask advanced vim users, are:
(1) Imagine that you had your memory of vim wiped, and you lost the ability to remember more than 10 commands. If you decided to learn vim again which 10 commands would you keep in memory?
(2) How many commands does somebody need to know before they can used vim productively? Is it less or greater than 10?
The questions I would like to ask advanced vim users, are:
(1) Imagine that you had your memory of vim wiped, and you lost the ability to remember more than 10 commands. If you decided to learn vim again which 10 commands would you keep in memory?
(2) How many commands does somebody need to know before they can used vim productively? Is it less or greater than 10?
I am an avid Vim user, and I also find such cheat sheets overwhelming. My pattern has been slow, incremental learning.
Starting from scratch is very intimidating. But when you have 10 commands in muscle memory, learning #11 seems pretty easy. When you know 50, #51 seems easy.
At first, using Vim was terrible. In a couple of weeks, I was back to "normal" productivity. In the 3 or so years since, I've continued to learn a new "trick" every few weeks or so, making notes in a Google Doc.
There is a long tail of commands, and no, you don't need all of them. But yesterday I created a macro that called a second macro, performing many complicated edits in my file in a few seconds that would have taken 10 minutes otherwise.
Was that worth it? Heck yes. It saved time, but even better, it felt awesome. The computer did my bidding.
Isn't that what programming is all about?
Starting from scratch is very intimidating. But when you have 10 commands in muscle memory, learning #11 seems pretty easy. When you know 50, #51 seems easy.
At first, using Vim was terrible. In a couple of weeks, I was back to "normal" productivity. In the 3 or so years since, I've continued to learn a new "trick" every few weeks or so, making notes in a Google Doc.
There is a long tail of commands, and no, you don't need all of them. But yesterday I created a macro that called a second macro, performing many complicated edits in my file in a few seconds that would have taken 10 minutes otherwise.
Was that worth it? Heck yes. It saved time, but even better, it felt awesome. The computer did my bidding.
Isn't that what programming is all about?
> making notes in a Google Doc.
Care to make that doc public? :)
Care to make that doc public? :)
The first Vim commands people learn generally fall into this set: i, i_<Esc>, gg, h, j, k, l, yy, dd, p, :w, :q. But any computer literate person should be able to operate on this level in a basic "Notepad" application. The be highly productive in Vim, I think you'll need to learn closer to 50 commands.
Now, if you think learning 50 commands is hard, think about your ability to touch type: that's at least 50 keys. Think about your programming language vocabulary. Think about your English language vocabulary. (Frankly, if I lost the ability to remember more than 10 Vim commands, re-learning Vim would be the least of my worries.)
Now, if you think learning 50 commands is hard, think about your ability to touch type: that's at least 50 keys. Think about your programming language vocabulary. Think about your English language vocabulary. (Frankly, if I lost the ability to remember more than 10 Vim commands, re-learning Vim would be the least of my worries.)
> any computer literate person should be able to operate on this level in a basic "Notepad" application
Yes, although I will say that <n>dd, p and P when properly wielded are a nice boost in power over optimal Notepad editing, even with mastery of the system-specific modifier key selection techniques.
Yes, although I will say that <n>dd, p and P when properly wielded are a nice boost in power over optimal Notepad editing, even with mastery of the system-specific modifier key selection techniques.
The thing is.. there's a really step learning curve in learning the fundamentals of vim, but once you know them, it takes a second to learn a new command.
For instance, dt' will delete characters until it matches a'. But also, dtf' will delete characters until it matches a' but also delete that '. T and F goes backward.. you can put a number in front of the command to delete until it matches the nth ', etc. It looks like a lot of command.. but it's all the same basic ideas.
So to answer your question, yes you can use vim effectively with less than 10 commands.. but once you know those 10, it's a matter of seconds to learn 100+ which would make you extremely more effective.
And as my "top" commands.. I'd say definitely:
For instance, dt' will delete characters until it matches a'. But also, dtf' will delete characters until it matches a' but also delete that '. T and F goes backward.. you can put a number in front of the command to delete until it matches the nth ', etc. It looks like a lot of command.. but it's all the same basic ideas.
So to answer your question, yes you can use vim effectively with less than 10 commands.. but once you know those 10, it's a matter of seconds to learn 100+ which would make you extremely more effective.
And as my "top" commands.. I'd say definitely:
ciw *deleting the current word*
cit *deleting between the current html tag*
ci) *deleting between the ()*
With surround plugin:
ds' *deleting the surrounding '*
cs'" *changing the surrounding ' for "s*
/ *incremental search*
o/O inserting new lines.Worth noting: cib == ci), and ciB == ci}.
Also, "a" instead of "i" includes the enclosing markers. Not really that useful for braces and parens, but for strings da" is great. da[ is pretty great for Obj-C, too.
Also, "a" instead of "i" includes the enclosing markers. Not really that useful for braces and parens, but for strings da" is great. da[ is pretty great for Obj-C, too.
(a bit cheating since it's more than 10, but just 10 is not enough for even basic use)
1) Cursor movement commands (hjkl)
2) Move by word (w and b) and page (^f and ^b)
3) Search for word under cursor (forward * and backward #)
4) File commands (:w, :new)
5) Split buffer (:split) and buffer movement (^w and hjkl)
6) Tab commands (:tabnext, :tabnext etc, bound to ",tn", ",n", ",p" etc)
7) File explorer (:Explore(), bound to ,f)
8) Move to start and end of file (gg and G)
9) Switch modes (v, V for linewise, i, esc)
10) Basic register operations (dd, y, p, P)
(To write these down I had to actually open vim and do the things I described - and for some, the conscious thought I put into it prevented me from actually doing it - says something about how ingrained they become)
1) Cursor movement commands (hjkl)
2) Move by word (w and b) and page (^f and ^b)
3) Search for word under cursor (forward * and backward #)
4) File commands (:w, :new)
5) Split buffer (:split) and buffer movement (^w and hjkl)
6) Tab commands (:tabnext, :tabnext etc, bound to ",tn", ",n", ",p" etc)
7) File explorer (:Explore(), bound to ,f)
8) Move to start and end of file (gg and G)
9) Switch modes (v, V for linewise, i, esc)
10) Basic register operations (dd, y, p, P)
(To write these down I had to actually open vim and do the things I described - and for some, the conscious thought I put into it prevented me from actually doing it - says something about how ingrained they become)
I prefer to think of the commands being organized conceptually, not by location. Something like this: http://fprintf.net/vimCheatSheet.html
So, if you are just starting out, learn the basic command(s) for doing each thing. Then, as you do it over and over, you'll begin to wonder how to do it easier. That's where the more advanced commands come in.
I do have printed cheat sheets that I occasionally will look at and say "oh, cool, that looks really convenient." But I'm not aiming for total mastery- just efficient use.
So, if you are just starting out, learn the basic command(s) for doing each thing. Then, as you do it over and over, you'll begin to wonder how to do it easier. That's where the more advanced commands come in.
I do have printed cheat sheets that I occasionally will look at and say "oh, cool, that looks really convenient." But I'm not aiming for total mastery- just efficient use.
Absolutely. My question is always "How do I ____, again?" The most hellpful cheatsheets are the ones that showcase alias commands, alternative commands, and related commands.
Thanks for the link.
Thanks for the link.
Also recommended: Mug of Vi (http://nostarch.com/mug.htm)
:)
:)
If you are calling every single button press a command then i(insert), m(mark), %(brace match), w(save), q(quit), /(search), s/(search and replace), y(copy), p(paste), d(cut).
That covers 90% of what I do in vim. Add in R (overwrite mode), o (start a new line), !(run a command at the command line then return to the file you were editing), crtl-ws (split windows), Ctrl-ww (switch windows),Ctrl-p (auto complete), various movement keys(I really only use h,j,k,l, $,^,Ctrl-f, Ctrl-b) and you have 100% of what I know about Vi. Definitely not a power user but it gets the job done faster than any other editor I have tried.
I find just the first 10 are faster than using notepad or its replacements. Throw in a few Vim addons like a source control plugin and tags, and it becomes fairly nice.
That covers 90% of what I do in vim. Add in R (overwrite mode), o (start a new line), !(run a command at the command line then return to the file you were editing), crtl-ws (split windows), Ctrl-ww (switch windows),Ctrl-p (auto complete), various movement keys(I really only use h,j,k,l, $,^,Ctrl-f, Ctrl-b) and you have 100% of what I know about Vi. Definitely not a power user but it gets the job done faster than any other editor I have tried.
I find just the first 10 are faster than using notepad or its replacements. Throw in a few Vim addons like a source control plugin and tags, and it becomes fairly nice.
@lhnz
I don't consider myself even a novice at vim. I know how to move the cursor in any manner that I need, I know how to globally search and replace, I use quick little commands like 'cw' all the time but don't know anything really advanced. My handwritten cheat sheet has about 15 or so commands on it and those alone have made me extremely productive in vim.
I don't consider myself even a novice at vim. I know how to move the cursor in any manner that I need, I know how to globally search and replace, I use quick little commands like 'cw' all the time but don't know anything really advanced. My handwritten cheat sheet has about 15 or so commands on it and those alone have made me extremely productive in vim.
Someone posted recently about a nice, step by step, tutorial:
http://news.ycombinator.com/item?id=2936670
Yup, really like that one.
[deleted]
Go through vimtutor (just type "vimtutor" in your shell), and you'll know the basics.
vimtutor is probably the very best introduction to vim that there is.
vimtutor is probably the very best introduction to vim that there is.
You can tell it's by programmers because it's fucking ugly.
This sheet does not achieve its specified goal. When using a tool, the question that always comes to mind until muscle memory kicks in is "how do I do this?" and not "What will pressing that key do?".
Think of it as a control settings in a console game menu: there are two ways to display the info, one is good design, the other is bad design.
Bad design: a list of buttons, and for each button the action. (ex: A = Shoot, B = Jump, C = Crouch...).
Why it's bad design: If you want to learn how to perform a given action, you need to parse the whole list to find the action, then look at the button, because there is no index. Likewise, if you want to change the button performing the action, you press the new button, scroll the list of choices, select the new action, press the previous button that was performing this new action, scroll the list of choices, select another action. One click, one scroll for each step.
Good design: list of actions, indexed in alphabetical order (or any order that makes sense in the context). (ex: Crouch = C, Jump = B, Shoot = A...)
Why it's good design? You can use the index to find the action quickly. Also, when changing the keys, just ask the game for a complete key remap and reply to each "press button for Jump", "press button for Shoot" etc with a single button press each time and no chance for a conflict.
A better design would be for this cheat sheet to display an indexed list of actions, and then the "motion" required to perform it - or a list of acceptable solutions. The problem with VIM as I see it is that it requires understanding an additional layer of abstraction: it's not "press A to Jump", but rather "press A to execute the action that is relevant to the mode that you're in: if grounded, jump and enter airborne mode, if airborne, jump and enter double jump mode, if in double jump mode, do nothing". Both do the same thing, but if what you're looking for is crossing a pit, the solution in both cases is simply to press A twice - except VIM is designed to be so powerful that there's no way to list actions without mentioning at least the possibility of side effects. On the good side, if you are proficient with VIM, plan things in advance and know exactly where you are compared to the pit, you can do a double jump backflip and shoot at the marker with a single keypress, and even add a numbered parameter to specify the number of bullets which can be a function of remaining ammo, distance to ammo bonus, number of enemies on screen and their toughness, etc. Sorry for the stupid metaphor, it kind of made sense while I was writing it but I can already feel bad karma coming my way :P
Think of it as a control settings in a console game menu: there are two ways to display the info, one is good design, the other is bad design.
Bad design: a list of buttons, and for each button the action. (ex: A = Shoot, B = Jump, C = Crouch...).
Why it's bad design: If you want to learn how to perform a given action, you need to parse the whole list to find the action, then look at the button, because there is no index. Likewise, if you want to change the button performing the action, you press the new button, scroll the list of choices, select the new action, press the previous button that was performing this new action, scroll the list of choices, select another action. One click, one scroll for each step.
Good design: list of actions, indexed in alphabetical order (or any order that makes sense in the context). (ex: Crouch = C, Jump = B, Shoot = A...)
Why it's good design? You can use the index to find the action quickly. Also, when changing the keys, just ask the game for a complete key remap and reply to each "press button for Jump", "press button for Shoot" etc with a single button press each time and no chance for a conflict.
A better design would be for this cheat sheet to display an indexed list of actions, and then the "motion" required to perform it - or a list of acceptable solutions. The problem with VIM as I see it is that it requires understanding an additional layer of abstraction: it's not "press A to Jump", but rather "press A to execute the action that is relevant to the mode that you're in: if grounded, jump and enter airborne mode, if airborne, jump and enter double jump mode, if in double jump mode, do nothing". Both do the same thing, but if what you're looking for is crossing a pit, the solution in both cases is simply to press A twice - except VIM is designed to be so powerful that there's no way to list actions without mentioning at least the possibility of side effects. On the good side, if you are proficient with VIM, plan things in advance and know exactly where you are compared to the pit, you can do a double jump backflip and shoot at the marker with a single keypress, and even add a numbered parameter to specify the number of bullets which can be a function of remaining ammo, distance to ammo bonus, number of enemies on screen and their toughness, etc. Sorry for the stupid metaphor, it kind of made sense while I was writing it but I can already feel bad karma coming my way :P
It's a comprehensive summary of the keyboard, I'm looking forward to studying it and extending what I know.
Now that's some visual clutter :(
There's simply no reason to think VIM is complicated or hard to learn at all :)
There's a better looking but less information dense cheatsheet here. http://www.viemu.com/a_vi_vim_graphical_cheat_sheet_tutorial...
I have it printed and taped to the window in the office.
There's a better looking but less information dense cheatsheet here. http://www.viemu.com/a_vi_vim_graphical_cheat_sheet_tutorial...
I have it printed and taped to the window in the office.
This cheat sheet reminds me of http://www.visibone.com/ 's Browser book, which has the same kind of density of information. Doing this well is very hard and while the idea is good, more work is needed to attain Visibone's level.
As a new programmer (I started learning Ruby and ROR about a month ago), the added value of learning VIM has already been paying off. Adding a new learning element into the mix (in this case VIM) does take some time at first, but once you realize how much time you can save in the long run there is no turning back.
Cheers for the colourblind one - actually makes a surprising amount of difference!
Very well made cheat sheet, but will it scare the new VIMers? I was using http://www.viemu.com/vi-vim-dvorak-cheat-sheet.gif when I started.
I'm far from a new VIMer and this scares me. While it contains a great deal of information, the noise level feels pretty high when I try to dig into it.
One useful command that was missed:
C-^ (aka Ctrl-6) switches back to the most recently used buffer. That is, if you are using two buffers, you can just flip back and forth with C-^
C-^ (aka Ctrl-6) switches back to the most recently used buffer. That is, if you are using two buffers, you can just flip back and forth with C-^
Of note:
1) OSX will not send any sequence when you press C-6 in Terminal.app. You have to press C-S-6 or C-^. I've never had this issue on Linux. Either C-6 or C-^ will work.
2) If you launch Vim with "vim file1 file2", the Ctrl-6 buffer switching will not switch you between file1 and file2 until you manually do it for the first time in that Vim session.
3) The Ctrl-6 switching is frame-dependent. The "previous buffer" is maintained locally between window splits or tabs in Vim, so you could have a vertical split that allowed you to easily swap between 4 separate files (i.e. 2 per side).
1) OSX will not send any sequence when you press C-6 in Terminal.app. You have to press C-S-6 or C-^. I've never had this issue on Linux. Either C-6 or C-^ will work.
2) If you launch Vim with "vim file1 file2", the Ctrl-6 buffer switching will not switch you between file1 and file2 until you manually do it for the first time in that Vim session.
3) The Ctrl-6 switching is frame-dependent. The "previous buffer" is maintained locally between window splits or tabs in Vim, so you could have a vertical split that allowed you to easily swap between 4 separate files (i.e. 2 per side).
This is awesome, thanks. Every day is a day to learn new stuff in vim. :)
Here's another that's better for learning Vim, it combines the cheatsheet with a tutorial to make a four-step progressive cheatsheet:
http://www.viemu.com/a_vi_vim_graphical_cheat_sheet_tutorial...
http://www.viemu.com/a_vi_vim_graphical_cheat_sheet_tutorial...
Seems like a lot of visual clutter to me (tried having it as background on a monitor running 1366x768, not pretty usable for me)
Many might find http://www.qitty.net/lnx/vim-cheatsheet.png helpful too.
Many might find http://www.qitty.net/lnx/vim-cheatsheet.png helpful too.
The "For Programmers By Programmers" is a bit unnecessary.
Is anybody else using it?
The look of the cheat sheet lives up to the 'for Programmers by programmers' part...
Ah Qwerty, can you make a version for the Dvorak typists?
Cheat sheet looks great!
One question though. IT has 1g as a shortcut to goto the top of the file shouldn't this be 1G?
One question though. IT has 1g as a shortcut to goto the top of the file shouldn't this be 1G?
The canonical way is 'gg'.
Is there an award for title redundancy?
vi(m) is for sys-admins. Programmers need to know
:q!
$ emacs !$
:q!
$ emcas !$
Fatal: NOT_ENOUGH_FINGERS (10 found 15 required)Let's make it attractive and say only "11 required" ;)
Unfortunately, my keyboard can only register 6 keys being down at the same time. This has thus far prevented me from successfully playing emacs.
I remember the old joke of emacs standing for Eight Megabytes (of RAM) And Constantly Swapping. Oh for the days when that was a lot of system memory.. Not really.
ooh ooh holy war, let me try!
more like emacs(ucks!)
more like emacs(ucks!)
Some how I feel deep down inside that vim was not designed bottom for this kind of complexity. I mean to say when you want to design something to scale you have to clearly decide what goes into the core and what can be added using a extension system. Although I understand the spirit behind the use cases for vi when it was first invented to light weight. Now when you decide to stick to minimalism you must be consistent to that philosophy. When you violate that, you go on bolting stuff on top of it which doesn't belong there. The net result is a huge bloat of things which make usability too complex. Besides I only can commit so many things to memory.
One look at this cheat sheet made my head spin. Every time I fire up a editor to write code, I need brain space to think about the problem at hand. I can't afford to context switch between looking a up a sheet of command to do editor work. Which in case even Notepad will turn up to be more useful than this.
If someone has a better way to doing this I would be more than happy to learn. I keep hearing a lot of vim these days, and want to learn it too. But everytime I face the uphill task of memorizing something, I just drop it and go on to do something else.