Vim Cheat Sheet - For Programmers By Programmers • Hacker News Board

Re: Vim Cheat Sheet - For Programmers By Programmers

#31

Post by babebridou » Fri, Sep 09, 2011, 12:53 PM UTC

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

Re: Vim Cheat Sheet - For Programmers By Programmers

#32

Post by kaishin » Fri, Sep 09, 2011, 12:56 PM UTC

The look of the cheat sheet lives up to the 'for Programmers by programmers' part...

Re: Vim Cheat Sheet - For Programmers By Programmers

#33

Post by roel_v » Fri, Sep 09, 2011, 1:07 PM UTC

kamaal wrote: post #7

I started out vim, with bare minimum commands but later on went to emacs. With emacs I have an option M-x tab auto complete In case I don't get to remember something. I would like to know what are vim equivalents of this? 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…

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.

Re: Vim Cheat Sheet - For Programmers By Programmers

#34

Post by danneu » Fri, Sep 09, 2011, 1:08 PM UTC

dhimes wrote: post #27

lhnz wrote: post #22

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…

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 sa…

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.

Re: Vim Cheat Sheet - For Programmers By Programmers

#35

Post by roel_v » Fri, Sep 09, 2011, 1:15 PM UTC

lhnz wrote: post #22

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…

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

Re: Vim Cheat Sheet - For Programmers By Programmers

#36

Post by pge » Fri, Sep 09, 2011, 1:16 PM UTC

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-^

Re: Vim Cheat Sheet - For Programmers By Programmers

#37

Post by roel_v » Fri, Sep 09, 2011, 1:19 PM UTC

brandoncordell wrote: post #28

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?

The canonical way is 'gg'.

Re: Vim Cheat Sheet - For Programmers By Programmers

#38

Post by [deleted] » Fri, Sep 09, 2011, 1:32 PM UTC

lhnz wrote: post #22

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…

[deleted]

Re: Vim Cheat Sheet - For Programmers By Programmers

#39

Post by chernevik » Fri, Sep 09, 2011, 1:38 PM UTC

babebridou wrote: post #31

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 = Shoo…

It's a comprehensive summary of the keyboard, I'm looking forward to studying it and extending what I know.

Re: Vim Cheat Sheet - For Programmers By Programmers

#40

Post by stonemetal » Fri, Sep 09, 2011, 1:47 PM UTC

lhnz wrote: post #22

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…

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.