Vim anti-patterns

  • Of all the "Vim tricks" article I came across, this one is my favorite so far.

    I have been a vim power user for a little over 2 years now. I never bothered installing plugins and spent all my time instead learning ... the exact same commands described in the article. Now I type fast, I mean real fast.

    A couple more tips I find useful:

    - 'gg' and 'G' in command mode will send you to the beginning and the ending of the file.

    - 'Ctrl-N' and 'Ctrl-P' in insert mode will auto-complete (suggestions only come from existing words in opened buffers, for more you'd probably need plugins).

    All the other tips are _spot on_! I especially like the first one about moving vertically one line at a time. It takes some time getting used to, but the fact that you can repeat the 'jump' or jump back to your previous position. Believe me, you'll fly :)

    My new set of advice for blazing fast typing:

    1. Learn to touch type. The rest is meaningless without this.

    2. Repeat 'vimtutor' religiously for 10-15 days.

    3. Read this post and apply every tip until it's hard-written in your fingers' muscle memory.

    4. ... voila!

  • Ok, I'm going to get a little blasphemous here, but I retain functionality of the arrow keys because they allow me to move the cursor while in INSERT mode. I find that ESC + [hjkl] + I to be slower than just using the arrow keys since the distance to escape vs arrows keys is about the same for the respective fingers (minus the cost of exiting and re-entering INSERT mode). I am sometimes told I should remap ESC to facilitate the use of hjkl, but the benefits seem dubious since I rarely have a need to move one or two spaces/lines outside of INSERT mode (instead, opting to traverse my code via line number, [], g/G, w/b, A/I, or marks).

    tl;dr - arrow keys vs hjkl makes little productivity difference to an experienced vim user (unless of course, you've baked hjkl into your workflow, but remember that the reverse is true as well)

    edit: I also find it productive to have one mental model for cursor movement as well as selecting splits or tmux panes.

  • I just started learning vim. It would be great if someone made a game for learning that taught some simple commands—something along the lines of, "Perform the needed operation(s) in the fewest number of keystrokes possible." For instance, add an attribute to an html tag with your cursor at a certain starting point on the line. Then have a leaderboard of the shortest key-combos used, with comments.

    I'll bet more experienced vimers could learn something from this, too.

  • One other major feature I would mention: text-objects

    text-objects are basically things Vim knows about that you can operate on with the "verbs" of vim (d/c/y etc). So, for example, if you're inside quotes, you can yank everything inside the quotes with yi" (to include the quotes, you use ya"), regardless of where the cursor is inside the quotes.

    For more information see :h text-objects

  • L, M, and H are also very useful for vertical movement. My general procedure for navigating (when I don't have anything particular to find), from general to specific, is: Ctrl-f/Ctrl-b, L/M/H, j/k).

  • The Escape key on modern keyboards is a lot further from home row than it was on Bill Joy’s keyboard back when he designed vi. Hitting Escape is usually unnecessary; Ctrl+[ is a lot closer, and more comfortable.

    That's not an "anti-pattern," that's an opinion. I think C-[ is uncomfortable as hell.

  • I've thought for a while that Vim could analyze how a user edits and spot repeated use of inefficienct techniques like these -- and then suggest the more efficient alternatives to the user. Implementing this could make a nice project.

  • These kind of articles always have a few new things in them, even of most of it is familiar -- I guess everyone just has a slightly slightly different set of indispensable tricks.

    The most most useful Vim trick I've seen recently is "set relativenumber". This makes Vim show line numbers relative to the current line. This is awesome, because it lets you easily jump to any line you can see. eg. you can get to a line marked "9" above the cursor by pressing "9k".

    It can be slightly tricky to get used to if you're used to absolute numbers (have to use gg more), but for me it's worth it.

  • After around 5 years of using vim, I'm at the point now where everything in this article and comment thread is already in muscle memory. My only advice would be similar to whats in other comments:

    * Learn to touch-type

    * Learn new features slowly, giving each of them time to find their place in your workflow.

    My questions for other vim power users:

    * What _epic_ custom mappings do you have? Steve Losh's <Leader>ev for editing .vimrc and <Leader>sv for sourcing completely changed how I use and customize vim... are the any others with that level of impact?

    * How have you mapped control of buffers/windows/tabs? Command-T buffer mode takes care of open buffers, and the default window/tab control mappings seem good enough for me, but I'm wondering if there's a nicer way for this interaction to work. Currently I've got arrow keys mapped to moving tab focus, but it feels like their might be a better way here.

    * Are there any fun and creative ways you've integrated with the shell/plugins? Here are some examples I've got:

    <Leader>r :!rake

    <Leader>rs :!rake spec

    <Leader>rl :!rake spec (test near this line)

    <Leader>gs :GStatus (fugitives 'git status')

    <Leader>gb :GBlame (fugutives 'git blame')

    * What's a nice way to do find in project? Both vimgrep and :Ggrep are OK, but I find it weird that I'm taken out of the editor for both of those... Ideally I'd like the results to open up in a buffer which I can then browse through in some nice way.

  • Here's a good tip I picked up recently when working with numbers:

    Increment a number on or after the cursor with Ctrl-A and decrement with Ctrl-X in normal mode. Saves a few keystrokes over having to replace or enter insert mode.

  • Okay, here's one that I've been stuck with. What does Ctrl-Z do in vim, and how do I "undo" it? I always have to kill -9 the vim process, and it sucks cleaning up where I was.

  • It's amazing how many articles like this there are, and how I always seem to learn something new.

  • Mm... Agree with those.

    I use vim a lot and I'd add these as things in vim I found to be major productivity sinks too:

    - using tabs

    Simply too finiky. Create windows using :split and :vsplit. Swap between them using control-W h/j/k/l or :winc h/j/k/l Also:

    CTRL-W =, CTRL-W N-, CTRL-W N+, CTRL-W N<, CTRL-W N>

    Especially useful on large visual terminals where you can have multiple files open all at once and swap between them without touching the mouse.

    - cwBLAH . . . . .

    agh. Use :%s/blah/BLAH/g

    :)

  • zt, zz and zb are great too. They redraw the screen so that the line the cursor is currently on becomes the top, middle, or bottom line of the window.

  • Re using the Caps key mapped to Esc. Many people are commenting they never use the Caps Lock key. I'm puzzled since I use it all the time. Do you not capitalise your constants or globals? Or maybe you don't write much C or C++; I'm not sure what the standards are for ruby etc.

    Autocomplete helps, but life without a CapsLock would be awkward for me.

  • This article only touches on the "c" noun. There are quite a few handy things which you can do with it, such as delete all the text between quotes and put you insert mode (ci").

    I recommend that anyone who doesn't use this give it a try, as it saves a few keystrokes.

    PS. I guess the "i" subject is useful too for operating "inside" specific characters.

  • I'm guilty of some of these anti-patterns (like for example the arrow keys) but honestly I feel incredibly fast and productive when using ViM. I'm afraid to drastically tweak my workflow at this point because I don't think the optimization will be worth it.

    Overall it feels like good advice but it's just not my cup of tea.

  • Wow, it's almost like you studied a video of me coding to write that post.

    Thanks. This will improve my vim-fu tremendously.

  • Question for wiser vim users than myself: If I delete (say, a line comment) with `D`, how do I paste it as a line of its own without macro trickery involving `o<esc>p`? Is that possible?

  • I like :sh and ctrl-d to bounce back and forth...

  • I prefer to keep using Echap so it works in a terminal with vi keybindings. The visual mode is not mentioned and this is super useful to see what you want to copy / delete. Also getting rid of the arrows is the way to go.

  • Judging by how frequent and popular these "baby steps with Vim" type posts are, I'm guessing that not many people on HN both use Vim and care enough about it to use :help.

  • > The benefits of getting to grips with Vim are immense ...

    This may be true, but IMHO it can't compare to dumping Vim and choosing an editor that more efficiently exploits modern computers and their interfaces.

    Many people don't realize this, but Vim arose from vi, which in turn arose from "ed". This family of editors contains a command infrastructure meant to avoid the waste of paper on a teletype terminal (ed's original display device).

    And how do I know this? I used ed, and an early version of vi, years ago during my NASA engineering days in the 1970s, while designing part of the Space Shuttle. All those separate vi modes -- insert, delete, move the cursor, and others -- originated in ed, at a time when it was a priority to assist the operator while typing blind, before wasting another 11 inches of paper just to see how it all turned out. The first version of vi was screen oriented, but it carried over the original separate modes, and kept them separate.

    When I wrote the first version of Apple Writer (http://en.wikipedia.org/wiki/Apple_Writer) in 1979, people had a hard time adjusting to an editor that allowed you to insert, delete and move the cursor without changing modes. It seemed a rather simple idea to me, but at the time, among vi users, it was met with shock and disbelief.

    And here we are, over 30 years later, and people are still learning vi/Vim, as though it represents cutting edge technology.

    I think we should hold a wake for vi/Vim, and maybe we should invite Fortran to the party.