Editors for Rubyists

Dhaivat Pandya
Tweet

editorsFor 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.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • demee

    Ruby Mine should be at the top of the list! But you ruby people, you worship vi and that other colorful notepads. Instead of using proper tools, you’re mumbling around documentation trying to find out whether that function had a bang at the end or not. But I guess everyone has to grow up one day, and that will be the day when Ruby will grow up too.

    • Jim Harris

      Real rubyists use [pry](http://pryrepl.org) for that — (code navigation/exploration/source/documentation). Vim or emacs + pry is a killer combination, I simply do not need an ID. i’ve also configured vim up the wazoo over the last 10 years and i’m super efficient/effective in that environment.

      • demee

        Thank You. You just confirmed what I just said.

  • ests

    I *never* use key in Vim/gVim. You have many alternatives (there is a nice article about it in vim wiki).
    And since I discovered vim-arpeggio plugin, my life have become even easier. This plugin allows you to define key mappings for (two) keys pressed simultaneously. For instance you can define ‘j’ and ‘k’ pressed together as . It sounds complicated, but actually works really well.
    https://github.com/kana/vim-arpeggio/blob/master/doc/arpeggio.txt

  • http://www.toddpickell.me Todd Pickell

    For Sublime Text 2 I use => http://wbond.net/sublime_packages/sftp to work on projects directly on my server instead of ssh then vim. It works very well. Sublime Text 2 has some great plugins.

  • Dave Goodchild

    On the subject of Sublime, I manage to work over ssh without any issues at all. And Vim users can always switch into Vintage mode if they need some old school Vim shortcut love. And you can use Sublime for free forever, with the full feature set. You do get messages after the evaluation period is over, and I would suggest throwing some cash into the project purely as a thankyou!

  • Akonwi Ngoh

    gedit is a nice simple editor. With the right plugins, it feels and looks like an IDE.

  • http://psionides.eu Kuba Suder

    Hey, where’s TextMate? :) For a long time it was *the* editor to use for Ruby coding, and it still has some faithful users.

  • Mike Chan

    You don’t have to press Esc in Vim to switch to the normal mode – CTRL-C will do the job.

  • Don Hill

    I do a lot of pair programming so I use VIM and tmux are the only choice. I also like the fact that I can map a key for anything I need todo.

  • Tony Martin

    I have to say, I have tried several options for Ruby/Rails editors/IDEs and the editor of my choice has been Redcar for q;uite some time.

    https://github.com/redcar/redcar

    It is a bit heavyweight in installation/startup time and sometimes window switching etc. But I love the editor’s features and ease of use. Syntax highlighting is pretty good.

    I was a bit disappointed, that development had been suspended, but I see it is now underway again. So hoping for great things to come.

    Tony Martin

  • Victor Hazbun

    We dont need IDEs.