Scala Development for Vim-loving Developers

Posted on October 6, 2015 by Richard Goulter
Tags: programming.vim, programming.eclipse, programming.scala

So, I’ve blogged a bit about Vim.
Again, no, it’s not about “vim vs emacs”, so much as about “which features your text editing has”; and the vi-like modal editing fantastic for manipulating text.

Recently I’ve had the fortune of programming in Scala.
The joke is that some programmers are happy to work in Scala because it’s not Java, the rest are sad to work in Scala because it’s not Haskell.
Scala is by no means an excellent language. (Again, there are two kinds of languages; those people use, and those people complain about). But I like it well enough.

For the most part, I’ve done my Scala editing in Scala IDE, which is a plugin built upon the much-maligned Eclipse.
– Overall, the biggest complaint to be had about Scala IDE, from my experience, is that ScalaTest can be a bit finicky, and will often refuse to “run all tests in package” or so.

– If I’m harping on about the benefits of Vim, why make use of Eclipse?
Well, for one, I have the Vrapper plugin installed. This is a great stop-gap measure; it doesn’t have every binding (by default, at least), and occasionally messes up, but mostly does the job. (When I had to use XCode, XVim was also a nice plugin to have).
Using Eclipse was the pragmatic best-of-what’s-available.

I’ve recently tried out making use of Vim proper for Scala editing:
I love autocomplete; to get autocompletion for Scala in Vim, the easiest way is using some omnicomplete front-end (like YouCompleteMe), and plugging Eclim as a ‘back-end’ to it. – Eclim can communicate with Eclipse, and provide the autocompletion. – The downside to this is Vim becomes heavy-weight. Like, really heavy. I’m fairly sure you have to disable automatic project-building, also, otherwise there’s a huge lag every time you save. That isn’t great. (As it was for me, without the automatic building, there’s still noticeable/significant lag when saving, if using Eclim).

The benefit is you get to use all the customisations/plugins Vim proper has.
e.g. vim-surround is quite useful for editing Scala.

My workstation setup in my lab has two monitors.
For the most part, unless you’re using a keyboard-based window-manager like XMonad, I’m inclined to believe that two monitors isn’t all that enhancing to productivity: If you can, with your keyboard, switch between workspaces; within a terminal, use tmux to switch between tabs/panes, then your keyboard becomes your second monitor. The benefit of added screen real-estate is countered by the cost of moving your mouse to the other window (unless you’re using a keyboard-based window manager, where you can easily/quickly switch focus without use of mouse. Alt-Tab doesn’t suffice).
– I’ve found a use for my second monitor:
SBT has a feature (which can surely be scripted for other tools/environments) that will run a command any time the source-files change. I’ve found it useful to set up two panes on my alternate monitor: one pane will run this loop with the “not slow”-tests, the other pane will run whatever program I’m working on. – Benefits/drawbacks of the latter are, of course, “your mileage may vary”.

Also, make sure if you’re building a binary-search function, you don’t leave out the base case.

– Anyway, the benefit of setting up this is it’s, again, a stop-gap measure for “vim not showing me syntax errors”.
Yes, vim does have that feature. Syntastic is nice enough; though (due to Vim’s age), doesn’t just-work as well as in Eclipse, and doesn’t do the red-squiggly-lines thing.
Quickfix is the more ‘legacy’ equivalent. And Quickfix is really nice (I’ve used it for an OCaml project). But the equivalent “sbt compile” takes a long time to run. SBT itself compensates for this by providing a REPL/shell, which is quicker, but doesn’t fit the vim/makeprg model. – There seem to be some Vim/SBT integrations, but I’ve not tried any of them. (The general theme is they will integrate with quickfix).
– If it’s not too distracting, it certainly is useful to have an at-a-glance view of “did I break anything?”, though, so it’s not strictly inferior in and of itself.

There are other things I more/less miss from Eclipse.
e.g. Eclipse’s editing just has a more “solid” feel to it, like you’re editing building blocks. This is probably the whole press-enter-to-select-option.
No doubt Vim can be customised to match this, but some of the auto-insertions are nice. (And, yes, provide nice inspirations for what an editor should have).
Convenience features like automatically-import-a-class which wasn’t otherwise in scope is useful.
– Particularly, though, and an example of “how good is your tooling” is “show type under cursor”. (These strongly typed languages, with type inference, like Scala, Haskell and OCaml, more/less demand editors with this feature).

– But another big difference between these is this:
When I’m using Eclipse, I put up with any inefficiency.
When I’m using Vim, I’m imagining what I could have to improve my tooling, what features would be nice to have to make things nicer.


Newer post Older post