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