Skip to content

Installing fuzzyfinder_textmate: Textmate’s Cmd+T in Vim

Thursday, February 4, 2010

When Jamis Buck switched from TextMate to vim, he found he missed one bit of functionality above all others: TextMate’s file finder, Cmd+T.

Being a capable programmer, he “took an evening” and wrote up a Ruby library to replicate this functionality.  Then he extended vim with a plugin called fuzzyfinder_textmate that called out to this Ruby library.

The results were terrific, and fuzzyfinder_textmate is my go-to solution for opening files in vim.  I almost never type “:e …” anymore.  I’ve yet to see anything faster at grabbing a file buried somewhere in a directory tree. This plugin is particularly useful for me when working on Rails projects, where vim’s ‘current directory’ is Rails.root, and everything I want to open is down at least one level.  If you’re not familiar with the plugin, here’s a silent-movie-style screencast Jamis put together when he released it.

Sadly, this terrific plugin has a bit of a problem: it’s a pain in the ass to install.

Jamis’ fuzzyfinder_textmate relies on a second plugin, called fuzzyfinder.vim.  The author of this plugin makes frequent changes, which usually end up breaking fuzzyfinder_textmate.  This got to be too much for Jamis, and he officially dropped the project a year ago.  Today, the latest versions of these plugins won’t work together.

However, thanks to several contributors and github’s forking, you can get this big mish-mash of libraries and plugins to work…provided you install exactly the right versions of each.  It’s a trifle annoying, but fortunately I’ve done the homework for you.  Follow the steps below and enjoy my favorite bit of vim functionality.

Installing fuzzyfinder_textmate:

  1. Make sure you’re using vim 7.2 (the latest, as of this writing).  It’s possible earlier versions work as well, but I can’t confirm these steps will apply.
  2. Make sure the vim you installed was compiled with ruby support.  Check this by running vim –version | grep ruby at the command line.  A result of +ruby means you’re good, -ruby means you DON’T have ruby support.  Debian/Ubuntu users can get a ruby-capable vim by running sudo apt-get install vim-ruby.  Another test to make sure you’ve got ruby support: type :ruby in vim.  Argument required is good.  Not an editor command: ruby is bad.
  3. Install Jamis’ fuzzy_file_finder Ruby library from here.  This is installable as a gem, but I strongly recommend simply git cloneing this repo, creating a ruby directory in your .vim folder, and placing the lib/fuzzy_file_finder.rb inside there.   This keeps this dependency in your .vim directory (rather than on a system gem you’ll forget about when you change servers), and enables keeping your vim configuration in a git repository (HIGHLY recommended).
  4. Install vim-fuzzyfinder version 2.22.3.  IMPORTANT: you MUST use this exact version.  Other versions (particularly anything NEWER than this one) will NOT work.  After installing, confirm it works by running :FuzzyFinderFile in vim.  You should get a pop up box with a list of files.  If you do you’re almost there.
  5. Install fuzzyfinder_textmate, but use sethbc’s fork from github.  Don’t use the version from Jamis’ repo as it will NOT work with the version of fuzzyfinder.vim we installed.  git clone again, and simply put fuzzyfinder_textmate.vim in your .vim/plugin folder. To test that everything worked, run :FuzzyFinderTextMate in vim.  If you get a popup box, you’re done!

If you’re having trouble, the most common culprit is that you’ve mucked up the versions.  This collection of files is quite finicky, and if you’re using the wrong version of any one things fall apart quickly.  After that, double-check you’ve got Ruby support.

If you’re still having trouble, do a git clone of my dotfiles.  My setup is confirmed working, so you can diff your copies of the library/plugins against mine.  Any differences mean you’ve got the wrong version.

If you still have issues, leave a note in the comments and I’ll try to get you sorted out.

Finally, if you found this post useful, I’d urge you to check out my screencast: Vim for Rails Developers.  In it, I’ll teach you the best plugins, external tools, and editing tricks for writing Rails code at top-speed.  If you write Rails code in vim, it’s sure to save you time.

Filed in general | | Comments (11)

New In factory_girl: Callbacks

Monday, November 23, 2009

Thoughtbot’s factory_girl has recently gotten a terrific new feature: callbacks.

They look like this:

Factory(:user) do |u|
 
  u.after_create { |user_instance| do_something_to(user_instance) }
 
end

Now, when you use Factory(:user) in your tests, the do_something_to method will be called after the user is saved in the database.  Also notice that you’ll be passed the instance of the user as block parameter.

There are two other callbacks now available: after_build and after_stub.  Their callbacks fire pretty much where you’d expect them to.

You can mix and match these callbacks on the same factory.  Multiple definitions of the same callback will be executed in the order you provide them:

Factory(:user) do |u|
 
  u.after_build { |user_instance| do_something_to(user_instance) }
 
  u.after_create { do_this_after_create }
 
  u.after_create { then_do_this }
 
end

I’m excited about this addition because of how much more flexibility this gives factory_girl.  There are some kludgy parts of my factories.rb files that will be more elegantly accomplished with these tools.

Accepting these little lambdas to be run later feels very lispy, something I take as a great sign.

For more usage details, check out the ‘callbacks’ section of the README.

And, if you’d like to read more about using Ruby’s blocks this way, Greg Brown has an excellent article on the topic (excerpted from his also-excellent book).

Filed in general | | Comments (2)

Making Github’s Code Readable

Sunday, November 1, 2009

I love Github.  We recently decided to become paid customers at work, and I’m tickled.

I also can’t stand reading code on the site.

Why?  Frankly, the text is plain old ugly:

before

Those italicized comments look like faintly-etched glass.  And the bolded bits look clumsy as well (check out the ‘m’ on ‘module’)!

What’s with the ugly?  Let’s ask Firebug:

firebug

‘Bitstream Vera Sans Mono’?  Never heard of it.  Haven’t got it installed.  If you’re on Windows or OS X, you probably don’t either.

Okay, so I haven’t got Bitstream, so it looks like we’re falling back t–oh my GOD it’s COURIER.

Yes, Courier.  Invented in the 1950s.  For typewriters.  I think I last used this font while editing GORILLA.BAS to mess with the speed and gravity.  No one should be using Courier anymore (unless you’re writing a screenplay).

Fortunately, there are two easy ways to fix this.  The first, you and I can do.  The second will have to be done by the Github guys.

What we can do: install Bitstream Vera Sans Mono.

Download it here.

Installation is OS-specific, but I bet you can figure it out.

Here’s how things look after the install:

after

Sweet mystery of life at last I’ve found you!  This is about…a billion times more readable.

Now, the experience of not having their first-choice font shouldn’t have been so painful.  If you’re going to lead with a talented but fragile rookie, make sure you have a dependable second-string something something sports analogy.

Anyway, the Github guys should change ‘Courier’ to ‘Courier New’ in their stylesheet. Courier New is an updated and refreshed grand-child of Courier, and it’s far more readable, especially when bolded or italicized.  Plus it’s just as widely installed as Courier.

Little change on our side.  Little change on their side.  Code looks beautiful; everyone’s happy.

Github — no longer a butterface.

Filed in general | | Comments (10)