Want to see the full-length video right now for free?Sign In with GitHub for Free Access
Now that you have a solid understanding of core Vim functionality and behavior, as well as how to configure Vim to your liking, it's time to kick things up a notch with plugins. Plugins are packages of Vim config code that can add functionality, mappings, and commands to your Vim as well as add support for new programming languages.
To start, you'll want to know how to install a plugin. We recommend Vundle which manages both the installation and activation of your plugins. You can read about the base configuration in their Quick Start guide.
Vundle is a vast improvement over the default mechanism of simply adding a plugin's files to your Vim directory. With Vundle both adding, and perhaps even more importantly removing plugins is extremely easy.
In order to add a plugin using Vundle, you only need to add a simple line to your vimrc like the following:
With that line in your vimrc and your vimrc loaded (
you can run
:PluginInstall<cr> in Vim to instruct Vim to download and
activate the new plugin.
Since Vundle only requires a single line in your vimrc to use a plugin, it
end ups working much like the Gemfile in a bundler managed ruby app. We don't
have to worry about keeping a full copy of each plugin's source code in our
dotfiles, but can instead simply track the
Plugin lines added to our vimrc.
Although both Ben and Chris continue to be happy users of Vundle, there is an alternative plugin manager called Vim-Plug which has been gaining popularity of late, including being recently set as the plugin manager in the thoughtbot dotfiles.
It has some stated benefits over Vundle including parallel installation and updating, shallow cloning for smaller install footprint, and on demand loading of plugins for faster startup time.
By default Vundle (and vim-plug) both expect the
Plugin reference to point
to a repository on Github. Generally this is fine, but in some cases a plugin
will only exist in the https://vim.org script archive and not on Github.
Luckily there is a project aptly name Vim-Scripts that mirrors all
scripts on vim.org to a Github repository. In those cases, you can simply
point at the vim-scripts repo like
and you're back up and running!
CtrlP is a fuzzy file finder that allows you to very rapidly find a file without needing to type out (or even know) the full path to the file. After learning it you'll never want to travel without it!
The main CtrlP window can be started with, perhaps unsurprisingly,
From there, you can type any portion of the desired file path to filter down
the file list. In addition, a number of mappings are available when CtrlP is
|Move up or down in the CtrlP results list
|Cycle through previous CtrlP searches (
<C-n> goes forward
|Open the highlighted file in a new tab
|Open the highlighted file in a new split
|Open the highlighted file in a new vertical split
The above list is only a sample of all the mappings CtrlP provides. Check out
:h ctrlp-mappings for the full list and details.
By default CtrlP will cache the file listing it uses to display results. This improves the speed of matching but means that the file listing can become stale and show incorrect results.
Instead, we recommend using the following configuration to instruct CtrlP to
ag, aka the silver searcher, to populate the file list and to never
cache the results. This is both amazingly fast, will always be up to date
since is does not cache, and will respect your
.gitignore file to ignore
build and tmp files.
" Make CtrlP use ag for listing the files. Way faster and no useless files.
let g:ctrlp_user_command = 'ag %s -l --hidden --nocolor -g ""'
let g:ctrlp_use_caching = 0
You'll also need to add
.git to your
~/.agignore to keep CtrlP from
displaying results from your git repo.
See this pull request to the thoughtbot dotfiles for more detail.
Surround.vim is a plugin by the amazingly prolific plugin author tpope. It extends Vim's command language to add new "verbs" for operating on surroundings like braces, parenthesis, quotes, etc. It provides mappings for adding, changing, and removing surrounding pairs that use Vim's powerful command language syntax and text-objects.
In the following mappings,
<character> can be any of
|Surround text-object with
|Delete surround tag (works on HTML tags)
Note Surround.vim can even change surrounding HTML tags. The syntax
cst, then waits for you to specify a tag (including the open
angle bracket). So a complete command might look like
cst<h3> to change the
surrounding tag to an
Another tpope original, Repeat.vim, supercharges Vim's
. command (
repeats the last change you made) and allows for plugins to hook into the
As an example, say you've just used Surround.vim to surround a word in a
<strong> tag with
ysiw<strong>. Without Repeat.vim you'd have to type all
that out again to strongify another word, but with Repeat.vim you can just
. and Vim will happily repeat the surrounding change on the new word.
Continuing with the tour-de-tpope, we now come to Rails.vim. This is a huge plugin with a ton of functionality, but one that is critical if you're working on Rails apps. It provides a number of commands you can use to rapidly navigate and work on your app. Some examples:
|Open the "alternate" file of the current (spec for model, etc)
|Open the "alternate" file in a vertical split
|Tab complete to open models by name
|Tab complete to open models by name
|Extract visual selection to a partial, replace with
In addition to the above commands, Rails.vim has a number of other tricks up
it's sleeve including updating Vim's file lookup path to support navigating
to views with
gf, Rails specific syntax highlighting, and a host more.
:h rails<cr> for a more complete listing.
Rounding out the tpope-apalooza we come to Commentary.vim. Commentary
teaches Vim another new verb, this one for commenting out a line or multiple
lines, using the command language of Vim. It's mapped to
gc (think "go
comment") and works on any text-object or motion, as you'd expect. Some sample
|Comment down two lines
|Comment out the current line
|Comment out the current paragraph
Rspec.vim is a thoughtbot original plugin that automates defining the Rspec command needed to run the current file or even current spec (based on the current line). This is amazingly handy when you're trying to optimize your TDD loop for rapid feedback.
Typically you'll map
<leader>t to run the current spec, and
run the whole spec file. Rspec.vim will even remember that last spec you ran
so you can jump over to an implementation file, make a quick change, and then
immediately re-run the spec from there.
Rspec.vim focuses on defining the spec command but allows you to specify the way in which you would like the spec run. In the video Ben demonstrates using another plugin, Dispatch.vim, but there are many other methods you can use to run the spec command.
Many users coming from other editors want something like a Project Explorer or directory tree. If your determined to get one, then NerdTree is likely what you want. That said, we recommend against installing NerdTree or similar plugins that attempt to provide an almost GUIlike directory tree.
Instead, we recommend using CtlrP most of the time, and Vim's builtin Netrw
directory explorer for viewing the files in a directory. Use
:e . to open
Netrw on Vim's current working directory, and then all your normal motions
<cr> to edit the file under your cursor.
Plugins are a great way to enhance your Vim, but like with all things in Vim, an incremental approach is recommended. Try to only add one or two plugins at a time to allow you to focus on and learn them. Evaluate your plugins regularly and get rid of any you aren't using anymore.