Giving Vim a Go
Monday, March 30, 2009
So I'm in the process of trying out Vim as a Rails IDE. I've been using Textmate (and the e text editor on Windows before it) for some time now, and while there are a lot of things I really like about both editors lately I've been running into some things that are really bugging me. The biggest has been slowness on large projects - Textmate in particular really seems to bog down when you have a lot of files in your project. I'm trying a few different things to help it out (this for instance) but those come with their own drawbacks. Nothing I've found yet solves the issue of inadvertently opening a giant log file and having Textmate bring my whole system to a grinding halt. I used Vim in college doing some systems programming, so when I decided to try out another programming editor Vim was the first one that came to mind. It's certainly not as pretty as Textmate, but it's about as efficient as you can get once you learn the shortcuts - usability isn't always about looking pretty. I've also used Emacs and Netbeans before and while they're both nice, Emacs is a bit more involved than I'm willing to attack right now, and Netbeans suffers from many of the same slowness problems I'm trying to get away from in Textmate. That goes double (or triple) for Rubymine.
Since I'm on a Mac, I decided to try out MacVim, which seems to have generally positive reviews. It's free and easy to install, and the Rails.vim plugin has been getting a lot of press lately. I took the plunge and installed the whole shebang - MacVim, Rails.vim, Project.vim, and the Vividchalk color scheme. I liked what I saw a lot at first. MacVim is easy to integrate with both the command line (the mvim command a la Textmate's mate command) and Quicksilver, Rails.vim has a lot of nice shortcuts, Project.vim has a more than adequate project view, and Vividchalk is easy on the eyes. About the only things I'm missing are the Ruby/Rails docs from Priit Haamer's Rails Dictionary, the Cmd-T file finder (which had gotten unbearably slow in Textmate anyway) and the Cmd-R functionality to run a single unit test. I'm sure all of these exist in the Vim world, but I haven't quite gotten to setting them up yet. One of my co-workers pointed me to Spicycode's Bringing Vim to the People, which is a handy bundle of Vim plugins and configuration for Rails developers. So that's where I'm at now - fighting with BVTTP's config. I like that it includes a lot of the configuration for common Rails-Vim functionality (including FuzzyFinder for replacing Command-T) but there are definitely some wrinkles. For one, I can't get :Rproject to open the current directory as a Rails project anymore, and can't for the life of me figure out why this command has just gone away. Installing ctags support for drilling into code and docs has also been a bit of a challenge. The bundle requires the exuberant variant of ctags (not the vanilla ctags included in OS X), and while that's readily available in MacPorts, it's also necessary to set the ctags binary path in your vimrc explicitly with a
let Tlist_Ctags_Cmd = '/opt/local/bin/ctags'lest you get strange and vague ctags usage errors like
Taglist: Failed to generate tags
The long and short of it is that the jury's still out for me on vim. Despite its wrinkles, Textmate is still a nice editor, and it's likely to remain my primary editor for when I'm pair programming due to Vim's notoriously steep learning curve. I'm going to keep at it and see what happens. At worst, it'll give me a better appreciation for the qualities of different programming editors. With a little luck, I'll be able to get a setup that addresses a few of my Textmate gripes without introducing too many new ones of its own.
Have some editor feedback of your own, good or bad? Hit us back in the comments.
State of the blog
Tuesday, March 24, 2009
To start out restating the obvious, this blog has been pretty dead for the last 6 months or so. There are a variety of reasons why that's happened, but in all honesty most of them are too long or boring to explain here - suffice it to say that there have been a lot of posts started, but none have been finished. This is not due to a lack of good material to write about. Rather, the cycle seems to be that an interesting but overly broad post idea turns into a half-written outline, which then becomes a half-written post, which then sits in the queue for months on end waiting to be finished because the effort required to fully expound on the original topic is way more than anticipated. While topic selection is important, topic focus is even more important. There's a delicate balance that needs to be struck to end up with a topic that's both interesting to read and feasible to write about in a meaningful way. What this means is that we're going to try to post more short and specific posts. The general topics of technology, usability, design, and Inkitecture news will stay the same, but hopefully the posts will become both easier to write (for us) and easier to digest (for you).
Oh, and we've also been working on some new sites. Stay tuned, we'll post more about those shortly. And this time I mean it.