In my previous post I walked through some of the plugins I use day to day for navigating a Grails project in VIM.  Here I’ll discuss some of the additional plugins and scripts that I use on a regular basis.  Not all of these things are Grails specific, but I’ll be sure to address any hurdles that I ran into on a Grails project.

Snipmate
Snipmate is a VIM plugin that attempts to reproduce the snippets feature of TextMate.  Not being a big TextMate user, I can’t say how well it succeeds, but I’ve found the plugin quite helpful.  Since VIM doesn’t provide much out of the box templating, it’s nice to have  something that generates boilerplate code for you.  Like many other plugins, there is no default Groovy file, but you can simply copy ~/.vim/bundle/snipmate/snippets/java.snippets to groovy.snippets and start adding your own.  The format is fairly straightforward.  It allows for static text, variables that can be populated in multiple places at once and default values.  For example you can define the following snippet for an each closure.

snippet ea
each { ${1:it} ->
	$1${2}
}

When typing ea<Tab> a call to each will see

each { it ->
    it
}

The first ‘it’ will be highlighted, enabling you to change the text that will be reflected on the ‘it’ within the closure.  Hitting tab will move the cursor to just after the second ‘it’ where you will be able to continue typing.  One of the advantages of Groovy is its terseness, so this might not be the best example of a snippet, but there are still cases where this can be very helpful.

VCSCommand
VCSCommand is a plugin that handles a plethora of version control systems.  Within any file that is under source control, you can type <Leader>l and see the version history of that file.  From there you can use the command :VCSVimDiff to diff the file with a specified version right inside of VIM.  If no version is specified it diffs the file with the current version.  You can also commit from here as well, although I must admit I generally move to the command line for this.

When using :VCSVimDiff, be careful to use :bd to close the versioned buffer.  If you simply use :q to close the window, the buffer will still exist and VIM will continue to highlight the changes.  If you forget, you can always use bufferexplorer to find the buffer and close it.

Speaking of VIMDiff…
VimDiff is a quite powerful merge tool, but has a learning curve almost as steep as VIM itself.  Default shortcuts are fairly unintuitive, but due to VIM’s flexibility this can be easily remedied.

I’m not going to cover setting up every version control system, but I do have configurations available for Git and Mercurial.  I’m using MacVim, but you should be able to replace ‘mvim’ with your vim command (e.g. vimdiff) if you’re using something else.

Git:
in your ~/.gitconfig

[mergetool "mvim"]
    cmd = mvim -df $BASE $LOCAL $MERGED $REMOTE -c "wincmd J"
    mvim
[merge]
    tool = mvim

Mercurial:
in your ~/.hgrc

[merge-tools]
vimdiff.executable = mvim
vimdiff.args = -df $base $local $output $other -c "wincmd J"

These configs will create a three way merge in vimdiff.  The local version will be on the left, the remote version will be on the right with the merged version in the middle.  The base version will be in a panel at the bottom.  By default, there aren’t very convenient shortcuts to copy changes from each of these files, but it’s easy enough to set them up based on the names given by version control:

For Mercurial:

map <D-1> :diffget orig<CR>
map <D-2> :diffget other<CR>
map <D-3> :diffget base<CR>

For Git

map <D-1> :diffget LOCAL<CR>
map <D-2> :diffget REMOTE<CR>
map <D-3> :diffget BASE<CR>

On Mac, ‘D’ is the command key in .vimrc. As you can probably guess, Cmd-1 will copy local changes to the merged file, Cmd-2 will copy from the remote file, and Cmd-3 will copy from the base.

One other item to note: If you mess up your merge, you can exit vimdiff with an error code by useing :cq

Testing
One of the things that you want to do most day to day is run tests.  The following scripts work pretty well for running tests in VIM.  F9 calls grails test-app with the current file.  Shift-F9 calls grails test-app with the name of the current method.  Typing :TestResults will open the test result html page.

"Grails testing
map <S-F9> <Esc>:w<CR>:call RunSingleGrailsTest()<CR>
map <F9> <Esc>:w<CR>:call RunGrailsTestFile()<CR>
map <D-F9> :call RunLastCommandInTerminal()<CR>
command! TestResults :call TestResults()

function! RunSingleGrailsTest()
    let testName = expand("%:t:r.") . "." . expand("<cword>")
    :call RunGrailsTest(testName)
endfunction

function! RunGrailsTestFile()
    let testName = expand("%:t:r")
    :call RunGrailsTest(testName)
endfunction

function! RunGrailsTest(testName)
    let path = expand("%:r")
    if path =~ "integration"
        let flag = "--integration"
    else
        let flag = "--unit"
    endif
    execute ":!grails test-app " . flag . " " . a:testName
endfunction

function! TestResults()
    silent execute ":!open target/test-reports/html/index.html"
endfunction

Although these scripts work quite well, the output isn’t as easy to view as I’d like.  If you’re running a Mac, this post, by Patrick Bacon has a great way to use apple script to send your test command to Terminal or iTerm2.  You can simply adjust the RunGrailsTest script above to call the RunInTerminal script from that post and all the shortcuts will work the same.

Another helpful item is to be able to run items in the grails console (or just a Groovy repl) from VIM.  This post, by Ted Naleid has a step by step on how to to both of these things.

Lastly there’s debugging.  Unfortunately VIM doesn’t have a built in debugger.  For in depth debugging I will still fire up an IDE on occasion.  There is a Groovy specific option for debugging though.  This post , by Aaron Babcock details his script for opening a repl at specified points in code.

There are many other things that can be done to customize your development environment in VIM.  While this might seem like a lot of configuration, it is what makes VIM so customizable and so powerful. To reiterate what I stated in the previous post, this is meant as a jump start into grails development in VIM.  I encourage you to customize your environment as you figure out what best works for you.