Vim Cheat Sheet - For Programmers By Programmers(michael.peopleofhonoronly.com) |
Vim Cheat Sheet - For Programmers By Programmers(michael.peopleofhonoronly.com) |
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.
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.
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.
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.
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.
In emacs, for word auto completion M-/ is just too awesome.
For example, :colo<tab> completes to :colorscheme.
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?
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
The sheet itself is really messy. I'd appreciate if anyone know a sheet that separates typical-editing and advanced-usage.
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.
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-^
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).
http://www.viemu.com/a_vi_vim_graphical_cheat_sheet_tutorial...
Many might find http://www.qitty.net/lnx/vim-cheatsheet.png helpful too.
One question though. IT has 1g as a shortcut to goto the top of the file shouldn't this be 1G?
:q!
$ emacs !$
:q!
$ emcas !$
Fatal: NOT_ENOUGH_FINGERS (10 found 15 required)more like emacs(ucks!)
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?
Care to make that doc public? :)
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.)
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.
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.dtf' should be df' in the above
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.
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)
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.
Thanks for the link.
:)
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.
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.
vimtutor is probably the very best introduction to vim that there is.