Improving my Vim setup

Today's post will be about setting up a Vim environment for Groovy programming, and shall hopefully be part of a longer series focusing on the kaizen philosophy, that is to continually improve. To put this whole thing in context, I've recently switched jobs for a much more flexible, agile consulting co-op, where I'm allowed to use the tools and technologies I prefer, in order to fulfill customer needs. Therefore, this puts me in a position where I'm always on the hunt for new ways to boost my productivity.

“Give me six hours to chop down a tree and I will spend the first four sharpening the axe.”

This quote by Abraham Lincoln is something software developers should be mindful of: always make some time to improve your work environment, and make sure you are well prepared before tackling a task.

With that mindset, I decided to dust off my Vim skills, which I had been using on-and-off for a quite some time, but mostly in the context of server administration stuff. Here are three of the improvements I've done with my setup:

• Version-control my vim config files with github
• Added snippet plugins
• Added special syntax-coloring rules for logging

While this is quite far from a complete list of how my environment is setup, they are three little productivity tips which might hopefully inspire you to go back to your development setup and improve it a bit.

Using GitHub for vim config files

I have recently converted to git for version control, I have been using it for everything; from synchronizing local version control with our remote SVN at work, to versioning my masters project. It came to no surprise that I decided to use git to solve the problem of keeping multiple work environments synchronized. Keeping your work environment on version control has a few advantages:

Multiple machine setup: naturally, if you have more than one workstation (alternating between your desktop and laptop as an example), having a way to easily synchronize your setup is essential.

With git already setup with github, all I need to do to synchronize my environments is

alex@hanzo:~/.vim$ git add *
alex@hanzo:~/.vim$ git commit
[master 8e72322] Added some snippets.
 1 files changed, 2 insertions(+), 0 deletions(-)
alex@hanzo:~/.vim$ git push origin master
Counting objects: 7, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 396 bytes, done.
Total 4 (delta 3), reused 0 (delta 0)
To git@github.com:bushibytes/vim-config.git
   f1a3fd4..8e72322  master -> master
alex@hanzo:~/.vim$

To save my setup, and

alex@linuxdev:~/.vim$ git pull
remote: Counting objects: 13, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 9 (delta 4), reused 8 (delta 3)
Unpacking objects: 100% (9/9), done.
From github.com:bushibytes/vim-config
   84825d1..8e72322  master     -> origin/master
Updating 84825d1..8e72322
Fast-forward
 after/syntax/groovy.vim  |    2 ++
 snippets/groovy.snippets |    2 ++
 2 files changed, 4 insertions(+), 0 deletions(-)
 create mode 100644 after/syntax/groovy.vim
alex@linuxdev:~/.vim$

To retrieve the updates on my other machines. Naturally, the repository needs to be cloned at first, and setup with github.

To get started with github...
Getting started with GitHub

Faster recovery in the case of data loss: while there's a running joke that Emacs users switch to vim when they lose their configuration files (those often being much more elaborate), the downtime of losing all your vim configuration can be significant when you're trying to be productive.

I so happened to have my hard drive replaced over the weekend, so I retrieved by vim setup by simply doing:

alex@hanzo:~$ git clone git@github.com:bushibytes/vim-config.git .vim
Cloning into .vim...
remote: Counting objects: 56, done.
remote: Compressing objects: 100% (45/45), done.
remote: Total 56 (delta 5), reused 55 (delta 4)
Receiving objects: 100% (56/56), 101.56 KiB, done.
Resolving deltas: 100% (5/5), done.
alex@hanzo:~$ cd .vim/
alex@hanzo:~/.vim$ ls
after     colors  ftplugin         plugin    syntax
autoload  doc     nerdtree_plugin  snippets

Note that I first had to log in GitHub and share my public key in my profile.

Sharing your setup: with a public repository like github (or semi-public like a company repository), it makes it a snap to share useful snippets with your coworkers, or to have friends review your setup and offer friendly advice (hint, hint).

As an example, if someone such as a fellow developer would want to clone my setup, they would just need to do:

git clone git://github.com/bushibytes/vim-config.git

Of course, make sure there is no private or sensitive information hiding in your config files.

Note that there's also many other viable alternatives for having your config files in version control; one that immediately springs to mind is using Dropbox to synchronize and backup your setups. Just make sure you have your setup backed up and ready to be deployed on a new machine, should the need arise!

Introducing the snipmate plugin

My vim-full install from Ubuntu had syntax highlighting for Groovy out of the box, so I was ready to do some code. After a bit of work however, I was starting to miss eclipse's auto completion and was looking for a way to make programming a little faster (especially for long, repetitive lines, which are thankfully not too common in groovy).

I fished around for a useful plugin and stumbled on snipmate for vim, which allows custom snippets.

Installation is pretty straightforward, and consists of just extracting it in your ~/.vim.

Once deployed, you'll find the snippet files in ~/.vim/snippets with the syntax <lang>.snippets

I made myself a groovy.snippets, by first copying the java snippet file (considering the java snippets can still be useful in groovy) and adding my  own.

In my case, I wanted to add some snippets to facilitate logging, so I added the following:

snippet logf
  log.logp(Level.FINE, "${1:`Filename()`}", "${2:main}", "${3}")

As well as other logging snippets. Let's have a look at the syntax. First off, you start defining your snippet with the snippet keyword, followed by your snippet name on a single line. This name will be what will be transformed when you press tab with your cursor on it. The next line, beginning with a tab, is the expanded snippet. You can put some arguments in your expanded snippet, which appear as ${n} or ${n:default} . The arguments are were your cursor lands after hitting subsequent tabs after expanding your snippets. Also note that we've used the special `Filename()` macro, which is substituted by the actual name of the file.

In this example, when you write logf in your code, then hit tab, it will tansform it into your expanded snippet. Hitting tab again will put you between the first quotes, which has the filename. Another hit will get you to the method name, and one last tab will get you to where you would put a login message.

Presto, logging is now a breeze!

Special syntax coloring rules

With my newfound powers, I went a bit log-happy in our applications, which made the code -less- readable, as my colleague Francois-Xavier remarked. Indeed, all those logging lines were rather distracting while reviewing code, so FX pondered for a lunch break to see if we could manage to get the best of both worlds.

He came up to me with two lines to add to my syntax highlighting (~/.vim/after/syntax/groovy.vim)

syntax match Comment "\v^\s*log(ger)=\.(exiting|entering|throwing|fine|finer|finest).*"
syntax match Comment "\v^\s*log(ger)=\.logp\(Level\.(FINE|FINER|FINEST).*"

What this snippet does, is that it takes any line starting with log (or logger), which contains log levels of "fine" and above, and colours it like a comment. The effect is rather remarkable: it tricks your eye into considering those logging commands as comments, which, for all intent and purposes, may as well be.

Have a look for yourself:

Picture before

Picture After

As we can see, a simple syntax coloring rule can do wonders to enhance your code's readability, while still keeping the logging there.

That's it for now, I might post a quick video of my setup later, just so I can play around with screencasting a bit.