Editing Paradigms

What makes a good term editor? Most people use either emacs or vi, and some people such as myself use both of them. Whilst I admire emacs for nxml-mode, vi is very helpful on OS X where even using the arrow keys is something of a pain due to the Apple keyboard layout. But each editor has something to commend it, even the editor that I sat down to write after posing myself the same question, "what makes a good term editor?", emano. Whilst emano is by no means an excellent editor, it has features which even emacs and vi lack. Why is it that even though Bill Joy expressed surprise in 1984 that vi had been around for so long, both it and emacs still continue to persist as top class term editors?

Part of the reason seems to be familiarity and establishment. These editors are well documented, and they were the first of their kind in each field: vi was the first modeful visual editor, and emacs was the first really good extensible editor. They both approach one of the most fundamental editing questions, how to bind relatively complex editing commands to keys when most standard keyboard keys are used for input. With vi, pressing the Esc key (which was located where Tab is now located on the keyboards that vi was originally written for), switches the function of the whole keyboard. With emacs, the modifier keys Ctrl and Alt are used to create a micromode. These are pretty much the only two approaches that can be made, and these were the first good editors to use those approaches.

There's also the question of extensibility. Both emacs and vi (as vim) are extensible, though of course emacs is the more so. That's probably why it prospers over vi, which although being faster to edit with doesn't have anywhere near the same level of customisability.

So what makes a good term editor? One that lets you edit quickly and transparently. We're dealing with arrays of arrays of characters, i.e. documents of lines and lines of characters. It used to be bytes, but times move on and now we have Unicode. The term editors are a little slow to adopt Unicode, of course, but they're getting there. I've been wondering if we've really reached the extent of what we're able to do with term editors with the line and character lowest common denominator for text. Sure there's syntax highlighting and a million langauge-mode extensions for emacs, but none of that has really revolutionised editing. Moreover, I don't even like syntax highlighting.

I started writing a short piece today about what I really want from a term editor, and I'm starting to come to the conclusion that convenience and robustness are two major factors that are now missing from term editors; because what we're using is old! As I already said, Unicode support has had to be bolted into emacs and vi, it's not a native thing. And I'm on OS X, and using vi because OS X makes editing a bit difficult anyway, yet vi isn't at least using the ways in which OS X makes up for that, with Spotlight and so on. The facility in TextWrangler to open a file by filename which is then found by Spotlight is one of the coolest features in any program ever.

This kind of clarity factor, the cleanness of the interface and so on, is something that I concentrated on in emano. I couldn't replicate the functions that emacs and vi provide, but I was able to trounce them in the modern design department, because it's been over twenty years since the newer of those was written. Instead of filenames, I used URIs and unified them with filenames. Instead of buffers I had tabs (though that might be a case of "you aren't going to need it", the other major problem that vi and emacs, and emano, have), and to find lines I provided a snazzy find-whilst-you-type interface, like the kind of filter boxes you get in Thunderbird or Apple Mail.

Bill Joy said that since he inflicted the most complex editor on the world, he'd love to write the most simple editor. He got started on it but didn't finish it: he was going to call it "be", a name with seven meanings. I'm not really sure what he had planned for it, but I'm wondering about writing something very similar, something which does the absolute bare essentials but does them very well, and then follows the whole unix principle beyond that by having an API that can be easily extended in any language, lots of small programs doing small tasks well. Somewhat like what emacs does, only ecumenical.

I'd like to track which keys I actually use on the keyboard more carefully, which characters in ASCII I actually tend to input into documents. It may well turn out, for example, that I don't use Tab all that much. In fact, I've already invested in that guess by mapping Tab to Esc in vi, just like it was when vi was first written. It's quite wonderful to use vi like that. Once I've done that, perhaps I can decide whether it's best to go the emacs way or the vi way, or even think of some other way about solving that big problem about how to actually get things done in an editor. Nobody seems to have thought much about multiple cursors, for example, or using all that screen real estate to draw something else than a dozen lines of context either side of the current point in the document.