Editors for Rubyists

For any growing language, there’s always a ton of tools you can use, as well as very strong opinions about them. Ruby is no exception.

There’s several editors, IDEs, etc. that all have excellent Ruby support aimed at keeping you operating at maximum “output” (I’m not one of those crazy managers that measures this output with lines of code, so, you get to choose how to define it). In this article, I’ll go over the advantages, disadvantages and odd points about each of them, from my perspective (read: the article is biased, but, my opinions are correct so it doesn’t matter :P).

Let’s open with a classic.

Vi(m)

Vi came to be in the days when bandwidth was small and people were patient with their computers. It ran inside your terminal/console, just nibbling on your memory and processor. The featureset was meant to be limited – it accomplished a few tasks, but it accomplished them pretty darn well. However, the limited featureset did not mean that it constrained you. With its simple and composable commands, vi became a favorite for those who cherished simplicity but needed flexibility and power.

Vi’s development gradually fell apart, as various people moved around in the project. But, fear not, because Vim was invented! Vim is a modified version of vi that is meant to offer a larger featureset while still remaining true to the vi vision of simplicity and respect of the power user.

So, what has vim got do with Ruby? Well, here’s where it gets a bit complicated.
Vim itself doesn’t really have any features specific to Ruby (aside from syntax highlighting), but Rails/Ruby hackers have always placed the console above a GUI in almost all of their decisions as a community. Vim fills that specification perfectly. In addition, vim has a number of extensions (NerdTree, ctrl+p, vim-rails etc.) that make working with Rails/Ruby applications pleasant.

There’s also nothing quite like watching someone experienced with vi(m) work – fingers flying across the keyboard, where seemingly half the characters typed seem to be inserted by vim itself. For those that do prefer a regular GUI for an editor, vim also include GVim, which is a version of vim using GTK (an interface toolkit).

But, vim is not all fun and games. Vim is a modal editor, which means that you can’t just go ahead and start typing and expect to be comfortable – there’s a pretty steep learning curve. There are three different modes: insert, visual and normal. Insert is one where you can type, visual is where you do things like select bits of text and the “normal” mode is where the keystrokes comprise vim commands. Getting used to this sort of arrangement can be really annoying, especially if you’re someone that has worked with IDEs and expect Ctrl+C to copy and Ctrl+V to paste (more on that later). One of the most annoying things about the whole modal arrangement (for me) is changing between modes. To do that, you have to hit the escape key. When you first hear of the concept, modes seem like something seldom used. The reality is, you change between modes all the time when using vim, and you have to move across your finger to the escape key EVERY SINGLE TIME. This is especially a problem for me since I have incredibly small hands; might not be an issue for some of you.

Then, there’s the command syntax. You get used to it pretty quickly, but it’s mostly devoid of “Ctrl”s and “Alt”s, using largely the alphabet (that’s why there’s the normal mode). Copy and paste seems incredibly complicated when you first start out. There are terms like “buffers” and “registers”, which you thought you’d never come across when trying to figure out how to use a text editor (of all things).

All in all, vi(m) is awesome if you can adjust yourself to it. Doing that is going to take at least some effort as well as a degree of determination to force yourself to keep using it (a bit like learning touch typing – there’s not much point unless you do it all the time). Additionally, if you’re coming from an IDE, don’t expect some IDE-like features such as it underlining all the errors for you – vim isn’t meant to do that (remember, simplicity is key!), so don’t expect features specific to e.g. Rails.

Emacs

Of course, now that we have talked about vim, so it is absolutely necessary to talk about Emacs.

I haven’t used Emacs all that much, but it does have some pretty nice Ruby support from the community. I’ve heard of a few who are quite happy with Rinari, which is an emacs mode for Rails in particular. There are many extensions that make Emacs more suited to Ruby development, such as test-runner, which is meant to be used with RSpec, Test::Unit, etc.

From what I’ve used of it, there seems to be far less support for Rails/Ruby (i.e. fewer people using it) than with Vim or Sublime Text 2 – this might be a problem if you run into trouble setting stuff up. Personally speaking, my tiny paws can’t keep up with the Ctrl and Alt shortcuts of Emacs, so I’ve stayed fairly clear of it. But, if you’ve used Emacs for other projects, there’s no harm in giving it a whirl for Ruby.

If you’re starting afresh, try both Vim and Emacs without installing any extensions, see what you like better. Once you’ve chosen one, write several blog posts insulting those who use the employ the other editor – it seems like a “coming of age” ritual, judging from the sheer quantity of such posts.

Sublime Text 2

This is one that I’m pretty excited about, especially because it is a nice GUI editor that doesn’t have so much stuff piled on it that it starts looking like Eclipse (shudder that brings back memories from Java). It’s comprised of a perfect middle ground between something like vim and a full-blown IDE.

I often find (especially when working with larger projects) vim starts to feel a little bit inadequate in terms of just coping with so many files. Switching between NerdTree (a file explorer) and the editing window feels tiresome, and typing in filenames into the “ctrl+p” extension even more so. This is where Sublime Text comes in. It is a GUI kind of deal, so if you need to work over SSH or something (I don’t know, maybe your company thinks Git and Puppet are for heretics) that might not work out.

First thing you notice is the clean and simple design – its just the editor and a file tree. I find this to be incredibly helpful in comparision to the Eclipse way of doing things where every thing under the sun that has anything to do with Java has a place somewhere near the editor. You might notice a small box at the right side of the editor – this the marvelous mini-map. It lets you know where in the source code you are (opening up a longer file will make this clear.) This is incredibly helpful when you’re moving up and down the source code hunting for that one variable that keeps setting itself to “false”.

ST also has a sensible and human-operable (without much effort) tab scheme that just works without getting in your way, unlike vim. ST doesn’t try to hide you from the “horrors” of the Terminal application (unlike most IDEs) – it simply “coexists”.

There’s a few downsides. First of all, if you are a hardcore vim user already, getting used to the new shortcuts is a little bit annoying. Secondly, if you are looking for an IDE, keep reading, because this isn’t one. Also, after you complete your evaluation of the product, you have to dish out a bit of cash to keep using it (although there’s no real time limit for evaluation).

Aside from that, I’m a really big fan of Sublime Text 2 and I like the direction that the project has taken.

RubyMine

This is the one I’ve had least experience with, but I like what I see. RubyMine is a complete IDE meant for Ruby and Rails. Filled to the brim with code completion, Javascript/Coffeescript support, git integration and a pretty cool GUI test runner. I’ve typically moved away from IDEs in general, but, RubyMine is really quite interesting. It doesn’t seem to suffer from the same issues as Eclipse and Netbeans (just too much stuff one screen) and has pretty awesome support.

But, of course, it is an IDE. That means that, if you had rather work in the console than anything else, you might not like it. It is also not the most customizable IDE in the world (as far as I’ve found), so if you want all the Eclipse plugin magic, it might be a disappointment.

Regardless, I think it is a great option and if you’re willing to let loose a little moo-lah, it might just work out.

Wrapping it up

Hopefully, you enjoyed my summary of some of the tools that Rubyists use to get stuff done. The easiest way to develop an opinion about one of these is to pick one, get thoroughly acquianted with it, and then try to change it up. If the change feels good, you might have found a better option. If it doesn’t, just roll it back! For extra points, write blog posts making fun of editors you don’t like and the people that use them.