There are Vim users and there are Scala coders and, occassionally those two wonderful things happen to get mixed up into the same person. I'm one of those people, and have finally gotten around to sharing how I code Scala with Vim in a screencast.

Watch it on Vimeo using this link, or just watch it below.

Coding Scala in Vim from Derek Wyatt on Vimeo.

The Workflow

This is exceedingly simple; it involves only two GUI elements: Vim and a terminal window.

MacVim and iTerm side-by-side

SBT does its thing in the terminal all day long (running ~test) while I get to code in Vim. Actually... that's about it. While inside Vim I use various plugins to navigate between files, and then classic Vim techniques to manipulate windows and do all of the text twiddling magic that all Vim users are used to.

  • ,fr opens a file using CtrlP from anywhere in the project.
  • ,fb helps me switch to a loaded buffer somewhere, again using CtrlP.
  • ,of flips me between a "production" source code file and its test file companion, and vice versa using some custom Vim code I wrote for Scala files.

It's possible that Vim is the second most important tool in my day-to-day, if not my Scala workflow specifically; the most important one is the Unix shell. I use ZSH, along with the oh my zsh configuration package and a custom plugin that interacts with Vim.

My experience with IDEs (and yes, I've used them) leaves me wanting in a number of areas, but one of the most crucial is any integration with the Unix shell. The ZSH plugin lets me talk to my running Vim instance from wherever I happen to be. If I couldn't do this, then I'd have to have my editor completely replicate all of the power I would otherwise be missing from not being able to use the shell.

What I Give Up

The Scala IDE gives you all the good stuff that you can get from Eclipse, including code completion, build integration, debugging, refactoring and so forth. I don't have any of that stuff in my workflow -- and I don't care :) If you really care, then my workflow isn't for you.

Honestly, I haven't used a debugger in many years now - I'm a caveman kinda guy, using log statements and println calls wherever I happen to need them. There are times when I am envious of code completion but I'm not willing to pay the speed price to integrate it with Vim. Every IDE I've used, as well as the pseudo-equivalent Vim plugins have a particular weight associated with them that just messes with my life.

Refactoring tools? Well, yeah... that'd be nice. But that's 1% of what I need and I'd rather optimize the 99%.

Simplicity

  • There are a ton of plugins for Vim and I do use a number of them, but I'm not a junkie about it. I have tried using the VimSIde plugin and the TagBar plugin, but neither were fast enough for me. The latter was pretty fast, but not terribly effective.
  • ZSH is key
  • SBT is, obviously, a big deal too.
    • I don't make any attempt to "integrate" SBT with Vim. A while back, I took a swing at it by using the SBT Quickfix plugin, but it just didn't fit with my workflow.
    • SBT runs in a separate terminal, doing its thing while I just code away; if SBT does something that requires my attention then I'll look at it, but for the most part, my peripheral vision takes control. If the screen's got RED on it, then I look... otherwise, who cares?

Plugins I Use

  • Scala Plugin - I'm the sole maintainer of this thing. If you're looking to help out, or even just file some issues, please do!
  • CtrlP Plugin - I used to use FuzzyFinder but was swayed to change due to the awesomeness (not to mention the active development of) CtrlP.
  • XPTemplate Plugin - This is the template generator that makes dealing with code boilerplate a bit easier.
  • BufKill Plugin - Makes it easier to kill buffers without wrecking the window layout.

My Configuration

I've got a few Github repositories that cover my configuration.

  • You can find my Vim configuration there, along with some scripts that pull in all of the plugins I use.
  • My dotfiles that configure my shell and various other things.
  • When I'm working in Linux, I use a keen window manager called Notion and Github holds that configuration too. How you navigate your window manager is pretty big deal to your workflow, and Notion is a ton better than the OS X window manager.

That's it. If it works for you, go for it. If it doesn't... well, you read this far? Neat.