Updates in Vim Land

In this post, I’ll show you the latest additions to my collection of useful Vim plugins: The Vundle plugin manager and the dwm.vim window manager not to be confused with the dwm window manager.

Vundle vs. Pathogen

Status quo ante

Just like many of you, I keep my “dot files” version controlled and backed up at GitHub. Moreover, I used Pathogen to bundle up all Vim plugins instead of having plugin files scattered around in autoload/, plugin/, etc. To automatize the procedure of setting up my configuration on a new machine, I came up with a mix of scripts:

  • A shell script that creates symlinks from the repositories dot files.
  • A Python script that checked out Git repositories of Vim plugins from a list of GitHub URLs and curl’d my favorite color scheme.
  • A Makefile with two targets: config that called the shell script and vim that called the Python script. Yes, it was that pointless.

This approach worked just fine for me but is obviously an ugly crutch. Moreover, I constantly forgot the make targets …

Vundle

[Vundle][] is a drop-in replacement for Pathogen which means all plugins living under bundle/ are managed in the same way as with Pathogen. Unfortunately, Pathogen does not know how to get the plugins, so it depends on some external magic to find them under bundle/. That is the reason why I have used this awful Python script and other people import plugin repositories via git submodule into their configuration repositories. Vundle solves this problem because it knows how to fetch plugins from different sources.

All you have to add to your .vimrc are two lines of boilerplate and a list of plugins from GitHub, VimScript and non-GitHub Git repositories. This smartness is a shining example of convention over configuration:

filetype off

set rtp+=~/.vim/bundle/vundle
call vundle#rc()

Bundle 'mileszs/ack.vim'
Bundle 'Raimondi/delimitMate'
Bundle 'Shougo/neocomplcache'
Bundle 'Shougo/neocomplcache-snippets-complete'
Bundle 'Lokaltog/vim-powerline'
Bundle 'kien/ctrlp.vim'
Bundle 'tpope/vim-commentary'
Bundle 'tpope/vim-markdown'
Bundle 'tpope/vim-fugitive'
Bundle 'nvie/vim-flake8'
Bundle 'matze/dwm.vim'

filetype on
~~~ 

So, instead of having the plugins magically appear, I can tell _from_ my
`.vimrc` what plugins I want to fetch and where from. To install the plugins,
you simply call `:BundleInstall` in a Vim session and watch Vundle installing
them:

<pre data-shortcode><figure>
  
  <img src="&#x2F;images&#x2F;2012-08-23&#x2F;vundle-installing.png" />
  
</figure></pre>

Plugins are updated with the `:BundleInstall!` (note the bang) and deinstalled
by removing the `Bundle` line from the `.vimrc` and calling `:BundleClean`.
Very simple.

[Vundle]: https://github.com/gmarik/vundle


### Status quo

Now, instead of maintaining a Makefile, a shell script and the Python updater I
distilled everything in a single [setup.sh][] that just updates the symlinks
clones Vundle. The rest is taken care of by Vundle itself. Life couldn't be
easier.

[setup.sh]: https://github.com/matze/configs/blob/master/setup.sh

## dwm.vim -- Vim windows done right

### Vim windows

[Windows][vim-windows] are part of Vim for a very long time and probably
confusing first time users since its very beginning. Other than windows being
_views_ on _buffers_ there is no direct relation between them. There can be
windows that don't show any buffer and there can be multiple windows that show
the same buffer but in a different way. That's the power of flexibility coming
at the cost of complexity.

For most of the time, I never really bothered with windows because I was mostly
switching between buffers in a single window with the [minibufexplorer][]
plugin. So, why bothering with windows then? Because I ditched minibufexplorer
some time ago and because it is often a good idea to see the contents of
different buffers at the same time. For this reason, I had key maps to create
windows and move between them. As you can imagine, the layout was static and
only determined by the order I opened them. Not very flexible and thus not very
often used by myself. Fortunately, there is a new and surprisingly simple plugin
on the Vim landscape that solves the problem of rigid window layouts.

### dwm is not dwm but almost

[dwm.vim][] is a plugin named after [dwm][], a _tiling_ window manager and
origin of my window manager of choice, [awesome wm][]. According to what I read
(I never used dwm), dwm.vim's mechanics are pretty similar to dwm's that sports
a single window pane M and one side and a stacked window pane S on the other.

Once installed -- preferably with Vundle -- you use `<C-N>` to create a new
window with an empty buffer in pane M. All other windows are pushed to pane S
and stacked atop. You switch to the next (clockwise) window with `<C-J>` and to
the previous with `<C-K>`. A stacked window is focused and moved to pane M with
`<C-H>`. In my setup, I use `<C-X>` to close the current window. This was
originally set to `<C-C>` by the author of the plugin. However, because I use
`<C-C>` to go from insert mode to normal mode, I sometimes accidentally closed
the window without intending to do so. This graphic sums the mechanics up pretty
well, I guess:

<pre data-shortcode><figure>
  
  <img src="&#x2F;images&#x2F;2012-08-23&#x2F;dwm.vim.png" />
  
</figure></pre>

Although I just started using dwm.vim, I already feel the same potential gains I
experienced after installing [CtrlP.vim][]. So, thumbs up (or like or +1), for
this nice little plugin.

_Update_: I contributed a patch that stops dwm.vim from mapping all those keys
and makes it much easier to override `<C-C>` with `<C-X>`.


[vim-windows]: http://vimdoc.sourceforge.net/htmldoc/windows.html
[minibufexplorer]: https://github.com/fholgado/minibufexpl.vim
[dwm]: http://dwm.suckless.org/
[dwm.vim]: https://github.com/spolu/dwm.vim
[awesome wm]: http://awesome.naquadah.org/
[CtrlP.vim]: https://github.com/kien/ctrlp.vim