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.

I've been using those more and more recently and have noticed a couple interesting things to be aware of. First, Vim interprets a dash character immediately preceding the number as a negative sign. (In playing around a bit I suspect this behavior is slightly influenced by the syntax rules for the particular filetype you're working with.) The effect of this is to flip the behavior of CTRL-A and CTRL-X. Secondly, if the first digit of the number is '0', Vim will behave as if the number is octal, so incrementing "07" once will result in "010". Similarly, a prefix of "0x" or "0X" will cause a number to be treated as hex.

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.

It's called VIM Golf. http://www.vimgolf.com

You might also be interested in http://stackoverflow.com/questions/2588481/are-there-any-kat...

Don't try to learn everything at once.

$ vimtutor is great. Do it a few times until you don't need to read it. It's not really game-y but it's quite challenging when you come from TextMate world.

Also there is a site called http://openvim.com that works more or less like what you describe. I hate it, though. I can't bear the tone and the forced jokes and it's nowhere near as well thought out as $vimtutor.

Others have pointed at vimgolf.

One of the cool things about Vim is that you always learn new tricks.

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

I like CTRL-U/CTRL-D for scroll up/down by half a screen, as opposed to a full screen.

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!

In case you missed it, this one will teach you much more than just a few commands... It's all about combining commands or producing 'sentences' as the author calls it:

http://yanpritzker.com/2011/12/16/learn-to-speak-vim-verbs-n...

I never bothered installing plugins and spent all my time instead learning

This wisdom should be shared with everyone learning vi/vim, since this leads directly to the largest payoff.

I dunno, Command-T was a pretty big boon to my productivity (https://github.com/wincent/Command-T).

The general idea is that if your productivity relies on external plugins, it will drop very low as soon as you have to use someone else's machine, or when you have to work with lots of various systems where setting up your environment isn't an option.

I don't mean to say that you shouldn't find and use plugins, because there are some really great ones that answer real needs.

But it seems that a lot of people new to vim get distracted by plugins, tweaking their config, et al, when they could be learning the "vi way" to get their actual code editing productivity.

If you don't use plugins, you are really missing out.

Check out PreciseJump and EasyMotion:

http://www.vim.org/scripts/script.php?script_id=3437

http://www.vim.org/scripts/script.php?script_id=3526

(watch the animated gif demos on those pages and be amazed!)

MRU is really useful for navigating the most recently opened files:

http://www.vim.org/scripts/script.php?script_id=521

xptemplate is an awesome, very advanced snippet plugin:

http://www.vim.org/scripts/script.php?script_id=2611

NerdCommenter, for easy commenting/uncommenting blocks of code:

http://www.vim.org/scripts/script.php?script_id=1218

And, of course, before you install any plugin, you should do yourself a favor and install and use Pathogen, or something like it:

http://www.vim.org/scripts/script.php?script_id=2332

For me, these are some of the most essential plugins that I use every day. Some other good ones are tabular, renumber, stripansi, matchit, and surround.

How long have you been using vim?

I'm also a fan of Pathogen (and tpope's stuff in general), but now I would recommend Vundle. It's like Ruby's Bundler for Vim. The difference is that you define the bundles (plugins) you want to use right in your .vimrc. With :BundleInstall/:BundleUpdate clones/updates these plugins.

https://github.com/gmarik/vundle

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

I've always used ':1' for the beginning and ':$' for the end. To me, the benefit of this is that I always use the same mechanism to go to a particular line of a file. (I often do, say, ':45' if an error is reported at line 45.)

For moving up and down large distances, I also prefer ctrl+u for up and ctrl+d for down. There is a minor difference: ctrl+f will put the last line at the top of the screen, filling the rest with the tilde-abyss. That always bothers me.

45G does the same thing as :45, so the people using gg and G can also remain consistent with their muscle memory.

a useful one is 'markers'. I use it a lot when jumping from place to place.

Example: :ma <-- sets a marker at the current cursor location named 'a'

later on, you can go back to this exact place by typing "a (that is quote followed by letter 'a' - the marker you named.

Note that you can have as many markers as you want.

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.

Other "z" commands (these are the ones I always get mixed up):

    :setlocal spell spelllang=en_us - turn on spell check
    z= - bring up list of suggestions
    zg - add word to dict
    zug - undo add to word
    zw - mark as wrong
    zuw - undo wrong
    :help fold
    zf<motion> - create fold (common motions '%', 'a{', 'a(' )
    zo - open fold
    zA - open folds recursively
    zc - close fold
    zd - forget fold
    zj - move to next fold
    zk - move to prev fold (up)

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

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.

tl;dr: type `fg`.

One nice thing about this setup is you can "stack" processes in the shell.

Say you're working on file_x, but file_x depends on header_file_y and file_z. file_x makes sense on its own, so you don't want to split a new pane; you just want to leave your workspace as it is and come back to it later.

Hit ctrl-z, and fire up vim with the new stuff you want. When you're done, quit the current vim session and come back to your old context with `fg`.

The key observation is this stacks inductively, so you cant tumble down the dependency rabbit hole and always come back to the context you were at originally. This feature alone has made it impossible to ever leave console vi.

It really came in handy in my Operating Systems class where I could fly around the codebase an order or magnitude faster than everyone else.

If you really need to go back to a particular context %[num] lets you go back to the nth suspended process, but this will corrupt your stack of processes, so `fg` won't be in a clean order.

That's an anti-pattern too. You should use one of the many ways of loading up multiple files in one vim session. I don't know what the best is, because I'm an emacs user, but I know there are many options.

Losing access all your editing state when you move to a new file is silly, regardless of editor.

It goes beyond just editing multiple files. I'm a huge fan of tabs in vim so I do a lot of :tabnew filename (which has autocompletion by the way) and mapped \tp and \tn to :tabprevious and:tabnext. I sometimes just open in a new file buffer like emacs does, no tabs and no window splits but when I'm done with the file I go back to the other one.

But I also use ctrl+z frequently, even more when I'm editing over ssh. Usually because I want to do something outside of the editor window not directly related to editing. Or it might be related to editing, it depends, I just want a shell. I may even have forgotten which file contains what I want to edit, so I might back out to a shell and use a find|xargs grep or ack command. Basically any time gedit users open the terminal for something in the middle of editing, I just ctrl+z (or open a new shell tab, but as mentioned ctrl+z is joy on ssh where a new tab means a new connection).

So I use ctrl+z. Also :!bash is stupid, but :r!cmd should be on the page. (It pastes the output of cmd into the file.)

Why not gt and gT? All the commiting/greping/chmoding/building stuff can be done from within Vim. You don't really need to get out of it unless you want to launch a curses program or an interactive SSH session. Eck, even in such cases I think it's way better to have multiple terminal windows or panes.

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 have caps setup as a third ctrl key. So at least for me Ctrl-[ is super easy to hit, as is every other ctrl based modifier.

I greatly prefer this setup. I never used Caps before and now I have a useful key in a useful position.

It depends on the keyboard layout, though. To write [ I need to type Right Alt + 8.

Many of the tips involving keys like {[^$ look cool, but are impossible to hit fast on a non-US keyboard.

Given how common the escape key is in Vim, I swapped caps-lock and escape, which IMO is vastly more comfortable than C-anything.

I have jj mapped to Esc in insert mode. If you type it quickly, the two j characters vanish and you escape out of insert mode. If you type them slowly you get two j characters in your text. I rarely need two j's in my text, of course, so it's a good escape key sequence, but pick whatever you want. I chose jj because it keeps me on home row.

Ick, that makes for lag if you just type 'j'.

Hopefully you type fast enough that by the time your brain noticed any lag on the "j", you are already a few letters down the line.

If you are too dependent on visual feedback while typing, you'll have a difficult time typing fast in any environment.

That said, I don't think I'd ever try remapping escape. I have long fingers though.

It's just an ugly way to do a mapping. I used to have some mappings like these in my rc, but I removed them in favor of similar ones that backtrack instead. If the author wants "jj" to be <ESC>, it can be done without the lag: You just check the previous character on 'j' and then take action accordingly.

Sometimes my muscle memory winds up telling me it needs. That's how I wound up mapping both jj and ;l to Esc. The first gets used when I've finished an insertion and am about to pause to think (it feels more emphatic) while the second gets used when I'm in flow and know exactly what I'm going to do next.

I once read a thread discussing the topic of Esc replacements and was astounded to learn that some people had reinvented chording: they mapped all the permutations of h,j, and k into Esc replacements and then simply banged all three at the same time to exit!

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.

I've tried relative numbers a few times in Vim, but always found it hard to adjust. But recently Jeff Kreeftmeijer wrote up a way to get the best of both worlds[1]: relative numbers in command mode and absolute numbers in insert mode or if Vim loses focus. Just another option to consider.

[1] http://jeffkreeftmeijer.com/2012/relative-line-numbers-in-vi...

If you train yourself, you can get good at guessing the line numbers, plus is makes you feel godly when you correctly dd the 17 lines you want.

That, or subtracting ;)

I swear the entire UI of Vim is made to make the user feel like a ninja.

I'm fairly sure the GP meant "dd", not "add".

Ah, I meant subtracting the current line number from the target line number to get the number of lines to jump, instead of just guessing.

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.

Cars? I'd have to learn to drive? What's wrong with my horse I already know how to ride?

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

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.

Many people don't realize this, but Vim arose from vi, which in turn arose from "ed".

So what if it "arose" from previous software? Should we hold a wake for the UNIX model? Everything as a file? Come on, it's 2012! I'll spare you a list of popular software that still employs metaphors from the 70s and just say that vim != ed. The robust plugin system alone allows vim to be pretty much anything you want, and I can't think of any features from any modern IDE that vim doesn't support.

So what if it "arose" from previous software?

You're missing the point that Vim still has the infrastructure of the original program -- it still has three separate modes: insert, delete and move the cursor, just as its distant predecessor did. This has no purpose except to agree with tradition.

It is all about effeciency. I find when I am not using vim I am less effecient. I like the seemingly minimal, ultra complex features of vim. I can count on some form of it being installed on most *nix machines. I can customize it to my liking...what can I say...I love it. To me, it is as modern as any editor.

I've never understood this obsession with editing efficiency among programmers. When coding I spend about 90% of my time thinking about what to type. A good IDE that really understands the structure of my code without twenty flaky plugins is worth much more to me than saving some keystrokes.

Typing efficiency I'm "meh" on; don't get in my way, but I'm not too worried about it. I've tried tons of autocomplete of every kind and tend to just turn it all off. Navigational efficiency is very important, though. If I want to look at a bit of code, fractions of a second count if I'm going to stay in flow.

This is very much personal opinion, but what I found with autocomplete is the time I'm typing the code I'm also using to think about it. Even on those surprisingly rare occasions where I manage to set up autocomplete that is both fast and accurate, it still didn't speed me up much. If I'm thinking so far ahead of my typing that I'm actually frustrated about the typing, that is typically an absolutely enormous code smell that something is very wrong, and I need to address the redundancy immediately.

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.

This isn't an issue if you've mapped ESC to jk or something similar.

<j><k><k><i>

OR

<up>

I prefer a single key to four, even if I have to move my hand off the home-row.

Arrow keys are fine in insert mode but it sounds like you might be spending too much time in insert mode rather than considering normal to be the default mode. Do you use arrows in normal mode too?

You really shouldn't be moving in insert mode. The only thing you should be doing in insert mode is typing new text (or erasing a few characters immediately before the cursor that you mistyped while still in insert mode).

Once you're outside of insert mode, you have a ton of options for moving around very quickly and efficiently. You are crippling yourself by using the arrow keys to move character by character or line by line instead of going out of insert mode, not to mention the time you waste moving your entire hand to the arrow keys and back.

That said, if you really feel you absolutely must move in insert mode, may I suggest mapping:

  control-h
  control-j
  control-k
  control-l

to move while in insert mode, instead of using the arrow keys. That way your hands can remain on the home row, and you'll continue to use the familiar keys to move around. (As for hitting the control key itself, I like to do that with the part of my palm that's right below my little finger, so I don't have to move my fingers from the home row -- it also makes for virtually no finger strain, compared to using your fingers to hit it).

But you should really try to wean yourself off the bad habit of moving in insert mode.

"But you should really try to wean yourself off the bad habit of moving in insert mode."

That's just dogmatism for the sake of it. There are certainly cases where it takes less finger movement to use arrow key movement (either by character or by word) in insert mode than it would take with switching to normal mode and doing hjkl movement.

I have seven years of professional avg personal daily use of vim and never bothered to leave the arrows. I don't move so often in insert mode, I just prefer my hands the be far from each other. Ijkl maniacs should stop repeating the same refrain over and over...

My favorite tricks: o in select mode, ctrl-y in insert mode.

Still looking for a good commenter for python (NERD commenter don't work for me)

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?

You mean that you deleted it with dd? Can you show a before and after of what you're trying to accomplish, because it's very likely possible. I'm just not sure what you're trying to do.

say I have a line here ( | being my cursor)

    callFunction(); |// HEY THIS IS A REALLY LONG COMMENT

From there, I hit D, which is the same as d$. I want to then paste it so I have something like

    // HEY THIS IS A REALLY LONG COMMENT
    callFunction();

But I want to do that without entering insert mode.

To break a single line into two lines on a whitespace boundary, one pattern I find myself using often is moving the cursor to the whitespace and hitting 'r<return>'.

(The 'r' command replaces the character under the cursor with the next key typed, without going into insert mode.)

Oh that's a nice trick, I'll remember that one. As an avid user of J I've been wanting its inverse.

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.

I've only been using vim full-time for a year and a half, but I'm slowly ramping up on things like window and buffer management. Probably my favorite life-changing trick is the quick macro:

nnoremap <Space> @q

It dramatically lowers the mental barrier to macro use (at least when you're starting out with macros). Where I use to use ragex search and replace I now instinctively go for macros, and I'm getting good at choosing the most robust commands for the situation. The pattern of qq => /foo => cwbar => Esc => Space-Space-Space is incredible. It's so infinitely superior to regex search and replace, and the fact that you can paste the macro and modify it as text is the cherry on top.

Nice! I think I might add that to my .vimrc. The only thing I'd add about macros is that I generally use them for multi-line transformations (i.e. they usually end with `j`). This means you can record your macro and the run `n@q` where n=the number of lines you want to run it for and q=the register where your macro lives. This is useful for annoying, repetitive syntax transformation tasks.

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.