TextMate: First impressions

I've had a bit of a chance today to take TextMate for a test drive, and unlike 2lmc and Erik, I must say that I'm pretty impressed on the whole. OK, very impressed. Sure, it has a few rough edges, but it is a beta. And there seems to me to be enough slickness there to promise good things for the future. It's very customisable and expandable, and I'm sure it won't be long before we're flooded with bundles to support syntax colouring, commands and snippets for dozens of languages. For now, the default tools are slanted towards HTML, PHP and Ruby. This is obviously disappointing if you're a Perl geek (or a Shell scripting geek, or a LaTeX geek). However, as I've mentioned before, I'm learning Ruby at the moment and it makes a nice change to find a text editor with really good support for Ruby.

As usual when I try out a new application, I headed for Preferences to see what I could mess about with. Hmm. No Preferences. I'll save you five minutes of hunting around on the menus and tell you that there's no GUI for the preferences. It says in the Help file that you can set some parameters at the command line using defaults write com.macromates.textmate, but you'll be working in the dark. Changes that you make to settings with the application running (like turning line numbers on or off) do seem to get saved automatically between launches. I don't know if there are plans to eventually implement a GUI for the preferences, but it would seem likely.

Another standard command that seems to be missing is Print. I say 'seems' because I can't quite believe that it isn't there — surely I must have just overlooked it somewhere? However, since TextMate includes such comprehensive tools for issuing commands on a selection or the whole document, it ought to be perfectly possible to pipe text out to lpr to print it, though I guess you need to convert it to Postscript first to do it that way.

With those gripes out of the way, let's get on with the cool things about TextMate. First, there are a lot of ways to customise it. You can produce a .plist file to specify syntax colouring and folding according to regular expressions, so it's perfectly possible to provide support for almost any language. You can record macros of editing sequences to automate repetitive sequences. I produced one really quickly to comment or uncomment selections with a # character. Your last macro is stored as a 'scratch' macro, that you can replay until you record another, but if you want to keep it, you can save it with a name and an optional hot key. Commands can also be stored. These are fragments of script (any of the scripting languages that MacOS X understands — Shell, Perl, Ruby, Python or Applescript) that can be performed on either the selection or the entire document. This is an enormously powerful feature, as you can either overwrite the document (or selection) with the result, insert it at the end, put it on the clipboard, show it as a tooltip or open an new document window. There's a nice example in the help file of setting up a command to search your document for the word under the cursor. It then shows you the lines containing the word in a separate window, and because it stores the line numbers for the results, you can select a line in the results window and see that line highlighted in your file. I set up a very simple command to send the selected text as Standard Input to wc -w and show the results in a tool tip. This means that I can select a block of text (or the whole document), and get the number of words in the selection in a tool tip.

There are snippets, which allow you to insert a mini template for some repetitively-used text (an if statement, an HTML anchor or a PHP statement, for example), and you can filter a selection through a command, which is ideal for munging text. Just to round things off, it's possible to write a line of code in your document and execute that line, inserting the result. This is handy for getting the current date, using the Unix date command, but it would be neater if you could choose whether or not to overwrite the line of code itself.

I think this is the really strong point of TextMate: if you have the ability to add in functionality (provided that you have a bit of scripting know-how), you can build a text editor with exactly the features you need and no bloat. It's like Vim in that respect. Even if you don't have the know-how, syntax files, commands and snippets can be packaged up in a bundle, so users can share useful tools they have created.

Lastly (but not leastly), I think that TextMate looks like it belongs in MacOS X. The tabs are pretty (in my opinion), and the folding is neat. If you fold some text and hover over the ellipsis which denotes some folded text you get a tool tip showing you what's hidden. That's a nice touch.

TextMate seems to be really polarising opinion. Perhaps we'll look back on the 6th of October as the day when Mac users got their own Emacs/vi-style holy war. "Ah, yes Grandaughter. I was there back in '04 when the BBEdit/TextMate wars started..."