Actions: | Security

Navigation: Home | Services | Tools | Articles | Other

Tips for the vim editor

In my not so humble opinion, learning to use an editor effectively will make anyone who works frequently with text more productive. And the more you get used to it, the less it impinges on your consciousness. Expertise with tools allows my brain to concentrate on what I'm trying to achieve with the tool, rather than upon the tool itself. Which is good, because I don't have any spare mind capacity. If I'm concentrating on my tools, I'm necessarily not fully concentrating on the task itself (cf. Kernighan on debugging[#]_).

I don't consider myself to be a power-user of any editor, but I have used both emacs and vim for years and am vastly more comfortable and productive at they keyboard when I make just a little effort to remember to use more than the most basic possible functionality.

I'm not going to distinguish between vi and vim. Every environment I work in has one or the other; if it's a machine that I work on regularly such as my desktop/laptop/personal server, it will be vim with all the extra goodies, and if it's just a remote server that is auto-provisioned, possibly transient and configured by a tool, while it might be either vi or vim, I probably don't care too much because I'm likely to only be making simple edits anyway, not writing either code or prose.

One day, I'll probably write something similar about emacs as well, but my vi article came first because when I started using emacs I wasn't writing articles.


These move up/down screenlines, that is not lines in the file, which is very useful if you have long, wrapped lines. Consider mapping these to up/down arrow keys.
These move the cursor to the middle, top or bottom of the screen/window.


If you have more than a single file open for editing in a single vim session, you'll likely want to move between them. They are referred to as buffers.

next,previous buffer
buffer destroy (aka "close file")
:buffers, :ls
list buffers
^^ (Ctrl+6 or Ctrl+^)
switch back to the most recently used buffer, switch between 2 buffers using repeated ^6


Your terminal (or window if you're in a windowed environment aka GUI) can be split so that you can see more than a single buffer at once. Commands to manipulate windows or to move between them are prefaced with ^w:

new window
next window
split vertically for side-by-side view
close window


1st non-whitespace
beginning,end of sentence
beginning,end of paragraph

More than ordinary cursor movement

move backwards/forwards by a page at a time.
move backwards/forwards by half a page at a time "up"/"down".
name a mark, move to a named mark.
move to the previous mark.


Search for the word under the cursor, forwards or backwards.
Search for the word 'most' when it is not part of another word, such as 'almost'.
Allow pattern matching (both search and replace) with special characters such as newlines. (For example: :%s/,/^M/g, to get the ^M character, press Ctrl+V followed by ENTER.


^n, ^p
Next and Previous completions.

Modify text inside delimiters

If you have a delimited string which uses ", ', <>, or similar, you might often want to change the contents. You can use a command of the form "ci>", where "c" is for change, "i" is for 'inner' and '>' specifies the delimiter.

The 'i' is a text-object motion, which is vim specific, and must appear after one of c/y/d. Also, look at 'a'.


Use registers in normal mode with "<registername><operator> such as "cy2y to yank 2 lines into register "c". In normal mode, you can paste from a register by using ^R<registername>

named registers. Append to registers (instead of overwriting) by capitalising the register name.
Most Recently Used
current/alternate filenames
display contents of all named registers


I'm using vim-pathogen to manage plugins. tpope has made lots of them, but of course there are many others.

There are about a zillion to explore, but here are some that I use:

And some that I mean to check out:

nerdtree minibufexplorer fugitive rhubarb unimpaired rsi obsession eunuch ragtag <>

[1]"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian Kernighan