Vim: revisited

I’ve had an off/on relationship with Vim for the past many years.

Before, I never felt like we understood each other properly. I felt that the kind of programming I’m doing is not easily done without plugins and some essential settings in .vimrc, but fiddling with all the knobs and installing all the plugins that I thought I needed was a process that in the end stretched out from few hours to weeks, months even; and it the end it just caused frustration instead of making me a happier coder.

Recently, I decided to give Vim another shot. This time around it was different – something in my brain switched and now for the first time in my life I’m proud of my knowledge of Vim. My philosophy of it has changed to “less is more”, my approach was more disciplined and my motivation stronger. And so you don’t spend as much time learning as I did, I am going to lay down some fundamentals.

Start with a basic setup – but not zero

I learned this the hard way: you shouldn’t start with a huge .vimrc file that you copied from someone else nor should you install every single plugin that seems useful at that moment.

This is a good starting point for your .vimrc:

set nocompatible                " choose no compatibility with legacy vi
syntax enable
set encoding=utf-8
set showcmd                     " display incomplete commands
filetype plugin indent on       " load file type plugins + indentation

"" Whitespace
set nowrap                      " don't wrap lines
set tabstop=2 shiftwidth=2      " a tab is two spaces (or set this to 4)
set expandtab                   " use spaces, not tabs (optional)
set backspace=indent,eol,start  " backspace through everything in insert mode

"" Searching
set hlsearch                    " highlight matches
set incsearch                   " incremental searching
set ignorecase                  " searches are case insensitive...
set smartcase                   " ... unless they contain at least one capital letter

Everything mentioned in this article is valid in vim running in a terminal as well as graphical (GUI) vim such as gvim or MacVim. A graphical vim setting offers extra features, but I’m not covering any of those here.

Guidelines for expanding your vim settings later on:

1. Never copy something from other people unless you know exactly what that particular setting is doing and you recognize that you’ve needed it before.
2. Don’t use too many plugins; start with 3-5 and add others as your skill progresses. Use Pathogen for managing them.
3. Overly eager plugins like Syntastic can actually hurt your development even when you’re not actively using them. Zap such offenders quickly.
4. Discover your Vim heroes and periodically check how they have set their editor up. A lot of people publish their dotfiles on GitHub.

You can view my personal vim configuration here.

Make it pretty

Aesthetics of your text editor are very important given the time you’re spending in it. You should use a good programming font for your terminal emulator: for example DejaVu Sans Mono or Inconsolata. This will affect vim running in the terminal. Next is the color scheme: pick one by cycling through available colors with :color <Tab>.

The quality of the color theme will depend severely on your terminal emulator. You should consider using a graphical Vim to reach the highest quality of typeface and color; a graphical environment can also offer extra options such as antialiasing and line spacing settings.

Find what are killer features for you

Right from the start, you’ll need to discover some power moves that’ll keep you returning to Vim rather than your old editor.

Vim has two main modes you need to care about first: the normal mode (where you move, perform commands) and the insert mode (where you type in text). The insert mode is on the surface nothing special when compared to your old editor: you press i, you’re in insert mode, now you type text as you normally would. Pressing <Esc> exits back to normal mode.

But it is how you enter insert mode that offers some advantage:

You can also enter insert mode by replacing existing text at the same time:

These shortcuts are a very compelling argument why Vim is more efficient at editing code than most editors.

For more information, see :help change.txt.

Learn to move

In Vim, efficient movement is everything. After all, most of your time is spent editing, not inserting text and code. Commands for selecting, changing, moving and transforming text all follow the same motion rules, thus making them fundamental in knowing Vim. For example, in the ciw command mentioned previously, the iw is a motion that means “inner word”.

Since there are too many different motions to remember at once, you’ll need some sort of a mnemonic to help you while learning.

Knowing where you want to go

When you think about it, you always know where you want to position your cursor before editing – if you can describe your intent to Vim, you can perform it faster than hitting cursor keys repeatedly or even using the mouse. In general:

• If you repeatedly (more than 2-3 times in a row) hit cursor keys to navigate, there is a better way.
• If you press backspace more than a couple of times to delete text, there is a better way.
• If you find yourself performing the same changes on several lines, there is a better way.

Here’s an overview of several useful methods for navigating your document, with the 2nd column indicating the corresponding backwards movement:

To me, the killer ones on this list are “word”, “WORD” and paragraph motions.

For in-depth documentation on motions, see :help motion.txt.

After the jump

Some of the above motions jump, and it is very useful to know how to backtrack those jumps. From the :help jump-motions documentation:

A “jump” is one of the following commands: ', `, G, /, ?, n, N, %, (, ), [[, ]], {, }, :s, :tag, L, M, H and the commands that start editing a new file. If you make the cursor “jump” with one of these commands, the position of the cursor before the jump is remembered.

Mastering jumps is insanely powerful. Suppose you edited one line, exited insert mode and now you are navigating the document to find out something. Now you want to continue editing from the same spot. The `. motion brings the cursor back on the exact place where the last change was made.

Another example: you are in the middle of a script and need to add some code, but that needs adding an extra require statement (or import, include, or similar) near the top of the file. You jump to the top with gg, add the require statement and jump back to before the previous jump with ``.

If you did multiple jumps, you can backtrack with <C-o>. Went too far back? <Tab> goes forward.

Yanking: copy & paste

Once you know basic motions and navigating around jumps, you can be efficient with copy (“yank” in Vim terms) and paste.

What isn’t obvious at first, but you’re gonna notice soon, is that Vim doesn’t use your OS clipboard by default for these operations; i.e. you can’t paste text copied from Vim in other apps and p won’t paste into Vim what you just copied from another program on your computer.

Vim uses its registers as its internal clipboard. You can even save yanked text into a named register of your choosing to ensure it is never overwritten and paste it later from that register if you need to paste it multiple times in different spots. Commands for selecting registers start with ":

The examples above show how you can explicitly opt-in to use the system clipboard via "*, showing that Vim does have access to the system clipboard, but doesn’t use it by default. The last example uses the "_ (the “black hole”) register, which is a way to discard text without copying it and overriding the default register.

You can inspect the current state of all registers with :registers. See :help registers.

Quickly navigate files

Real-world projects have more than one file to edit. Efficient switching between files is just as important as motion commands.

Core Vim features

In the same session, Vim remembers previously open files. You can list them with :buffers (shortcut: :ls). Without even using any plugins, you can jump to a buffer on this list by typing :b and a part of a buffer’s name. For example, if you’ve previously opened lib/api_wrapper.rb, you can return to it with :b api. Hit <Tab> to cycle between multiple matches.

To switch between the currently open buffer and the previous one, use <C-^>. This key combination is a bit hard to reach, so you can remap to, for instance, twice hitting <leader>:

nnoremap <leader><leader> <c-^>

Since my <leader> is set to comma, I just have to hit ,, to alternate between files, for instance tests and implementation.

Folks coming from TextMate, IDEs, or gedit will quickly find themselves craving for a directory tree side pane, and the community is going to unanimously recommend NERD tree. Don’t use the NERD tree. It is clumsy, will hurt your split windows workflow because of edge-case bugs and plugin incompatibilities, and you never needed a file browser pane in the first place, anyway. If you need to view the directory structure of a project, use tree command-line tool (easily installed via package manager of choice, such as Homebrew on OS X) and pipe it to less. If, on the other hand, you want to interactively explore the file structure while in Vim, simply edit a directory and the built-in Netrw plugin will kick in; for instance, start in the current directory :e ..

ctags

A lot of the time you’re switching to another file to jump to a specific method or class definition. Now imagine that you can do this with a keystroke without knowing which file actually holds the method/class.

Using tags requires a bit of forethought, but boy is it worth it! It’s the single most useful feature for navigating source code that I’ve ever experienced. It just requires that you generate the tags file up front, but don’t worry: there are clever ways in which you can automatize this step.

You need to install exuberant ctags first. On Mac OS X: brew install ctags.

To generate the tags file for your Ruby project, for instance, do this on the command line:

ctags -R --languages=ruby --exclude=.git

You can do this within Vim too: just start the command with :!. This will generate the tags file, which is a search index of your code. For languages other than Ruby, see ctags --list-languages.

Now you can jump to a method or class definition with a single keystroke, or by specifying its name with the following commands:

• <C-]> / :tag foo — jump to tag under cursor/named
• g<C-]> / :tjump foo — choose from a list of matching tags

You’ll get hooked on this quickly, but you’ll grow tired of constantly having to regenerate the tags file after changes or checkouts. Tim Pope has an automated solution using git hooks. And if you often open code of installed ruby gems, he got you covered as well.

Fuzzy file searching

What you need for larger projects is a plugin for fuzzy searching of file names in a project. I find the Command-T plugin very capable and fast, but it requires ruby on the system and vim compiled with ruby support (MacVim is by default, so no worries there). If for some reason that’s a deal breaker for you, some people swear by ctrlp.vim.

Here are my mappings for starting a file search with Command-T. I start a project-wide search with ,f and search the directory of the current file with ,F:

" use comma as <Leader> key instead of backslash
let mapleader=","

" double percentage sign in command mode is expanded
" to directory of current file - http://vimcasts.org/e/14
cnoremap %% <C-R>=expand('%:h').'/'<cr>

map <leader>f :CommandTFlush<cr>\|:CommandT<cr>
map <leader>F :CommandTFlush<cr>\|:CommandT %%<cr>

For this to be fast, ensure that you don’t have any other mappings that start with <leader>f, otherwise Vim will always force a slight delay after keystrokes before resolving the mapping. (See all of the current mappings in effect with :map.)

Split windows

You can split the current buffer horizontally or vertically. This is useful, for instance, to view simultaneously the top and the bottom part of the same file. But it’s even more useful to view different files in splits; for instance tests and implementation.

To switch cursor between these windows, use <C-w> (as in “window”) and then direction, where direction is one of: ↑k ↓j ←h →l. To ease this navigation, you can use the following mappings so you can omit the <C-w> prefix:

" easier navigation between split windows
nnoremap <c-j> <c-w>j
nnoremap <c-k> <c-w>k
nnoremap <c-h> <c-w>h
nnoremap <c-l> <c-w>l

For more information, see :help windows.

Addendum: Essential plugins

During 6 months of using Vim after publishing this article, I now feel confident enough to share which plugins I find essential for daily work. This is subjective, but you should know that I’ve tried using core Vim features long enough to actually experience the pain while coding without these.

Command-T

I still use Command-T every minute of the day. Read more about it in the previous section.

Ack

:Ack performs an ultra-fast project-wide search using ack command-line tool. Can’t refactor without it; e.g. I don’t dare to rename a HTML classname without checking first whether it’s used in CSS or JS.

Commentary

Commentary adds key bindings for commenting & uncommenting code. At first I’ve used a combination of <C-v> (blockwise visual mode) and I (uppercase ‘i’) to insert a # character at the start of multiple lines. However, doing that a lot is cumbersome, and uncommenting is not so straightforward.

With Commentary, select some lines. Press \\. You’re done.

Tabular

If the style guidelines for your project require aligning assignments or other syntax vertically, use Tabular. Don’t ever ever keep aligning stuff vertically without a plugin–I’ve been there, and I feel bad about it. Simply select some lines, and :Tabularize assignment.

Surround

At some point I realized that a significant part of editing code involves manipulating pairs of matching quotes, parentheses, brackets, and tags. For that I started using the Surround plugin, and I’m loving it. For instance, ysiW] (“you surround inner WORD, bracket”) surrounds the current “WORD” with square brackets.

But the non-obvious, killer feature of Surround is the ability to generate or wrap existing content in HTML tags: e.g. ysip<C-t> (“you surround inner paragraph, Ctrl-tag”) prompts you for a tag name and nests the current paragraph in it. Need HTML attributes? No problem, just type them after the tag name. Read more tips for Surround.

Further resources for learning

• :help – may look daunting and unfriendly at first, but is actually more useful and in-depth than most resources found on the Internet.
• Coming home to Vim
• VimCasts
• Destroy All Software – there are some episodes on Vim
• VimGolf – time-consuming but rewarding game
• Walking Without Crutches – presentation slides by Drew Neil
• Practical Vim – book by Drew Neil
• My vim configuration and plugins

Thanks Gary Bernhardt, Drew Neil for tips and inspiration, and Tim Pope for all your work on plugins.