Text Editing

Text editing is a weird thing. Every developer — nay, every computer user (but not every solitaire player) — has their own “unique” perspective as to what makes for a good text editor. And, of course, everyone else is wrong.

For anyone that has been pushing ASCII for more than a decade, there is guaranteed to be some “glory editor of days gone by” that every editor today is compared against. Yet, somehow, nothing measures up. Never mind that the code or text one was writing a decade ago was completely different than it is today.

For me, I caught the emacs taint almost 20 years ago (sheesh!). And caught it I did! Within a few years, I had a 100K init file. A few years after that, and I had a multi-megabit “initialization environment” that could magically customize itself based on operating system and emacs derivative.

It was awesome. I could code Obj-C or Perl (yeah, I did Perl for a while, too) like a daemon. Everything was beautifully formatted, builds happened in Emacs, yadda yadda yadda….

And then Project Builder was born out of the original Interface Builder (PB was a tab in the main IB document window) and it became the way to build NeXTSTEP apps. Same goes for WebObjects. Fortunately, there were some fellow emacs infected folk on the AppKit team and NSText (NXText) gained key bindings that gave the basics of text navigation and manipulation through a set of emacsen key bindings. (There was also Edit. It kicked butt.)

And time marched on…

Xcode has evolved and is now a great Coca development environment. But the world is full of so much more than Cocoa code. I edit lots of random text documents, scripting languages, non-Xcode based Obj-C projects, commit messages, etc…

So, I need an editor that works from the command line, integrates with the GUI, and doesn’t suck. Now, keep in mind that suck is entirely defined by my own little unique history of text editing fun.

I tried emacs with the emacsclient mode turned on. OK. Emacs-y goodness, but the various GUI versions of emacs are broken in various ways. I guess once it makes the transition to a full-on, multi-windowed, GUI, it becomes abundantly clear how unlike any other application ever emacs really is. Painful.

TextEdit doesn’t do command line. In particular, I need the command line to wait until the GUI closes the window. At one point, I modified TextEdit to do command line based editing, but that was lost around Mac OS X PR 1.

So… guis guis guis…

SubEthaEdit is actually quite nice. Does coloring well. Has a nice command line tool. Simple. And the collaborative editing mode is just too damned cool for words. Use it all the time at conferences. Paid for a license a few weeks ago. But, yet, it is completely lacking in any of the macro-y, automated, mode-specific goodness of Emacs.

I have tried (and tried again) to like BBEdit. It is an incredibly powerful, kitchen sink like, editor. Does everything. Has a great command line tool.

Yet, I can’t stand it. Using BBEdit literally makes me grind my teeth with the general discomfort it causes. Now, I know that’ll rub a few people wrong (if anyone reads this) so let me be completely clear: BBEdit is a brilliant product and my inability to deal with it is entirely in my head. I think it is because BBEdit is neither a Cocoa app (which implies a certain amount of expected behavior for me) nor an Emacs derivative. It comes from a world that I missed — I developed Mac software professionally in the ’80s and then moved on to NeXT and network based Unix derivatives.

I have also tried a couple of the other random OS X specific editors… don’t even remember the names because they didn’t survive on my hard drive for more than a few minutes.

Now, the problem is solved. I have finally found an editor that seems to take the general user can customize everything philosophy of Emacs and shoves it into a generally really easy to use and elegant Cocoa interface.

TextMate.



10 Responses to “Text Editing”

  1. James Duncan Davidson says:

    Indeed. TextMate is good stuff. I’ve been using it now for a while. The very first versions of it made me grind my teeth as well… But then, somewhere along the way, it morphed into the pretty good tool it is now. It gets used non-stop as part of my daily life.

    Now–here’s the fun part. Get the Bitstream Vera Mono font for use with it–bump it up a point size or two and turn on anti-aliasing. Beautiful!

  2. Red Sweater Links » Blog Archive » Xcode came from Interface Builder says:

    […] I recently had a discussion with some folks about whether Interface Builder should be pulled into Xcode or not. According to Bumgarner, Project Builder (Xcode’s predecessor) was originally a tab in the main Interface Builder window. What a trip! Link. […]

  3. Chris Ryland says:

    Funny, I share the same Emacs bug from around 1977, and rejoiced when finding the Cocoa text-handling emacs-compatible keystroke stuff in Mac OS X (though you have to install the appropriate keyboard maps).

    And I tried various Emacs GUI versions, but they always got it wrong (and AquaMacs is getting it wronger by the week), so I went back to the pure Terminal version recently (with the option-as-meta key preference turned on in Terminal). This has the distinct advantage that I can run the exact same Emacs locally or remotely on my server. (And a few disadvantages such as no mouse selection, etc.). And the font handling in Terminal is quite nice–you can set both kerning & leading, effectively, to really customize your experience and cram a lot of lines on the screen (with a 30″ monitor, that’s a lot of lines). And it’s certainly anti-aliased.

    That all said, I’ve been meaning to try TextMate. I presume you can make it feel like Emacs as much as you desire?

  4. Jon H says:

    Actually, there were three stages of Project Builder.

    First, there was the primitive stage where it was baked into IB.

    Then there was the three-app stage where PB was separated out from IB, but Edit was used for editing, and Terminal was used for gdb, with some integration with Edit. At some point, they added a gdb control panel to Edit.

    Then ProjectBuilder gained a text editor. Then came XCode.

  5. sjk says:

    Hey Chris,

    Funny, I share the same Emacs bug from around 1977, and rejoiced when finding the Cocoa text-handling emacs-compatible keystroke stuff in Mac OS X (though you have to install the appropriate keyboard maps).

    Ahh, another TECO Emacs veteran. Can’t recall if I actually used it first on MIT-ITS or TOPS-20 (while at SRI).

    Even with simple Emacs key bindings in Cocoa apps, basic text editing is much more comfortable than without them.

    I presume you can make it feel like Emacs as much as you desire?

    Adding a useful subset of Emacs-like commands to TextMate (e.g. some C-x- prefix favorites) didn’t look particularly obvious for someone inexperienced to do when I briefly explored that possibility last year. In response to my asking about that in Key bindings for switchers, Allan Odgaard (TM’s creator) wrote:

    The key bindings route sounds about right. I know Brad Miller (sometimes on ##textmate) has a bundle that recreates most of the Emacs stuff he was missing, though with time I think this bundle has shrunken in size.

    Then I got distracted with other projects, never followed up with Brad, and stopped evaluating TM.

    Now, Bill’s post and your comments have piqued my TM curiosity again, with renewed hope of finding at least a few folks who’d be interested in collaborating on Emacs-related hackery for it.

    Nostalgic subnote: Found this BUG-LISP archive from 1981 with “Chris Ryland” and “sjk” in it.

    PS: Apologies for any botched formatting; bbum’s weblog-o-mat begs for comment preview.

  6. sjk says:

    Fooey. First paragraph in my reply should be a blockquote of Chris’ comment. Feel free to fix that and delete this comment, Bill. Thanks!

  7. Donovan Preston says:

    I tried TextMate when it first came out, when the original Ruby on Rails screencast used it and people were talking about how TextMate was to Ruby as Xcode is to Objective C. I tried it again last week, for a few days. I used it for editing all my Python, and I liked it quite a bit. However, it doesn’t do proportional fonts, and it’s Python code folding is absolutely horrendous. It also doesn’t seem to have the ability to put the line numbers in the gutter. Having already paid for SubEthaEdit, I couldn’t spending more money on an editor that was just OK.

    As many times as I have tried to replace it, SubEthaEdit continues to be the right combination of simplicity and comfort. Sometimes it gets really slow to respond to keystrokes but other than that I don’t have any complaints.

    I also tried Smultron, which seemed nice except you can’t open more than one editor at a time, and ScrIDE, which just looks ugly.

  8. leeg says:

    Edit.app had some useful features (piping through UNIX commands being one) which TextEdit lost in the horrendous Java-portage times of Rhapsody. But then that’s not really my ‘one true editor’: I think if the Xcode editor were available standalone and customisable I might be swayed by that 🙂

  9. jacobolus says:

    Ieeg, in case you ever see this again, google for Mike Ferris’s Text Extras. It’s a pretty cool input manager that adds most of that old Edit.app stuff into every Cocoa text widget.

  10. bbum’s weblog-o-mat » Blog Archive » BBEdit vs. TextMate: The Editor Wars Revisited. says:

    […] I have written at length about this before. […]

Leave a Reply

Line and paragraph breaks automatic.
XHTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>