What would make the best terminal editor?
The basic idea of editing an array of lines is pervasive. The only thing that's really changed since the introduction of the terminal is Unicode and multibyte systems. Other than that, we're still editing basically arrays of lines, which are arrays of characters (previously bytes).
Terminal editors are good. There's emacs, vi, and my own creation emano. All of these are good in their own special ways. But if you look back at Bill Joy's 1984 interview, he sees vi as being transitory, couldn't even believe that it had lasted ten years. I wonder what he'd think of it now? At any rate, vi lasted a long time because the idea of a moded editor was a good one, and allows for a particular type of editing. With emacs, you get extensibility, but you also lose a lot of speed too, so they're complementary. With emano, I wrote it in Python, but I think you have to write editors in C these days still just for respectibility. Even though Python allows for cooler extensibility and works just fine--we don't have to worry about term lag now.
In any case, emano was my first try at making a better, more progressive, terminal editor and I think it got a lot right. It tried to work from a very modern point of view with tabs, unicode, decent URI handling and all that; but in some ways it couldn't even really touch vi or emacs, and I use vi and emacs now mostly.
A good editor is one that lets you edit quickly and transparently. Basically you want to enter characters into and then manipulate that array of arrays of characters. But the structure held by the editor itself doesn't actually reflect well the structures that people enter. We work in paragraphs, lines, markup, programming structure. We work with structures that we then enter into this lowest common denominator, lines and characters. That's why syntax highlighting and the python-mode paradigms are popular.
But they're both just examples of huffman encoding your entry and manipulation routines. Customisability is most likely the key: we all edit in different ways doing different things, and our text entry habits change over time. The main key factor is deciding which things it's worthwhile to have a completely new mechanism for, and which it's best to stick with the usual method of entering regular text for. So is it better to have Esc-J in vi be something to join lines, or should I just be able to remember Esc-$-Delete?
Essentially, anything one does in an editor is an operation. The most basic operations are entering characters. Moving around is the next most basic level. But this can easily build up to very complex activities such as XML validation and so on; things that only a programming language can solve. It's like compression, where you look for operations that you're doing a lot and you abstract them out into a key that can be expanded later; but abstracting takes time and effort to learn. So does compressing a file.
This is related to the question of text input, or rather, the problem thereof. You've got a regular keyboard, and most of the keys are your basic alphanumeric characters. What key combinations do you assign to the less basic operations? This is the problem that vi and emacs solved so very differently. With vi, the way to do it is to have separate modes which make the alphanumerics behave differently depending on a toggle. With emacs, you use modifier keys, which are like a microtoggle, only working whilst the modifier key is held down.
Which is the best way of doing things? It seems that the vi way is the hardest to learn but results in better editing. On the other hand, it may be that the emacs way is best for throwaway optimisations, and it may be that throwaway optimisations are the main warp and weft of editing.
One way of approaching which keys are best to use for which tasks is to look at existing files and see which characters are actually entered frequently. For example, the original vi was written on a keyboard which had its Esc key where Tab is nowadays. This makes vi make a lot more sense! Since Tab isn't used all that much even now, it's possible to remap Tab to Esc in vi, which makes the whole vi experience a lot nicer. This essay is being written in vi with Tab mapped to Esc.
The only ways to find this out are to look at existing editors' features, and to analyse people's text input methods. The former appears to be done much more than the latter. Then it's a case of pattern analysing, to extract the most common operations, and then working out the best way of linking the operations with the input mapping.
Then I think it's important to make sure that the customisability is open ended, such that people can continue the huffmanisation themselves, and the looking for patterns. Or perhaps editors should become more advanced at doing that themselves.
Obviously there are some primitive operations. I/O is one of them: opening and saving a file is very important. And it's actually a very tricky problem: what if you want to edit a file that's 300 MB? You might need a whole way of optimising that, reading out line positions into a big array so that you can seek more easily; only writing out changes to a kind of diff file before applying them. Thankfully, the direction that computers are headed means that this should be less and less of a problem; the hardware should eventually be able to cope with ridiculous sizes of text.
The most fundamental thing here is that it seems that screen editors are the way to go now. Both emacs and vi are screen editors, and who uses ed any more? But if vi and emacs are the next step up from ed, what's the next step up from vi and emacs? There might be more subtle ways of using a screen to display a file for the purposes of editing it.
As for display of status and state other than which part of the file is being edited (which takes up the vast majority of the screen), is much really needed? Both vi and emacs are fairly light on this. Mainly, one can hold this sort of information in the mind quite easily. As long as vi has a bit of a hint as to which mode one is in, that's usually sufficient. Some people like to make sure that they can tell their current position in the file, with "set ruler", but perhaps they're just using that as a crutch. Current filename is usually known, unless you basically forget what you're editing, which might be the case if you come back to a term after having gone to do something else. It's the old "you aren't gonna need it" thing.
You also obviously need to be told when a file has been saved successfully... but do you really? What guarantee is it? And couldn't editors just save automatically? I'm kinda tired of having to save all the time. I want to be able to just edit the file "live", having the file reflecting exactly what I've typed in it at the moment. Because of the way that filesystems are designed, this is very hard: you'd have to rewrite the entire data to the file on every keypress, which is rather difficult... but this is the editor's problem, it shouldn't be the user's problem. Perhaps autosaving on exit, a la ZZ, is enough in this department... but I instinctively want to Esc-:w right now.
Perhaps emacs and vi are at the boundary of what terminal editors can achieve, but for example, having a hybrid so that I could use nxml-mode in vi would be probably advantageous. But then there's Mimulus, which is pretty much orthogonal to all of that. I should be editing this document in Mimulus for example, but I'm not. This document could quite easily be an h1, h2, p, p, h2, p, h2, p, p, p, h2, p, p structured document, and then I'd be able to add the all important hyperlinks to things like Bill Joy's interview.
This is the first time I've really used vi for a signficant amount of time in ages, and one of the main configuration options that I'm missing is scrolloff. It's disconcerting being on the bottom line and not knowing whether this is at the physical end of the file or not. Actually, "set scrolloff=1" doesn't seem to make any difference when you're in insert mode and getting to the bottom of the screen, so that's one clear way in which vi could be improved. Though it only does that if you do Esc-Go. Rather inconsistent.
So perhaps that's the main thing I'm lacking from editors: consistency and purpose and direction. Perhaps vi and emacs have got it basically right but I want something that's a more modern evolution, without all that cruft. Bill Joy wanted to make the anti-vi and call it be. Perhaps I could make a Simple Editor, or Optimised Editor or something like that. Lightweight Editor?
It wouldn't be able to nxml-mode things though. Or perhaps it should do, perhaps there should be no limit to it, even if it is lightweight. If it's open source, there technically wouldn't be a limit, but...
Open files using the command line.
I don't actually open files using the facilities inside term text editors, and nor do I make any use of tabs or buffers or whatever you want to call them. It might be worth learning those, perhaps? Or what if there were a decent browser system inside the editor? What if they had an "open by filename" facility on OS X using Spotlight, like TextWrangler?
Save files using editor function.
See above for this one. Should editors be able to save automatically? Why do I have to make incremental saves? Why don't I feel that the data is save until it's actually written to disc?
Input unicode.
This might fall under YAGNI, but very occasionally I do want to enter Unicode, and really text editors are screwed up when it comes to Unicode. They don't seem to think in terms of Unicode. And terms weren't made for the display of Unicode, though I suppose that's becoming less true now. OS X seems to be able to display the interrobang pretty well.
Create new documents quickly.
I don't want to have to worry too much about locations. There are only a few locations that I save new documents too, anyway. Probably easy enough to have a catalogue of them.
Move about easily.
One of the main reasons that I'm using vi on OS X is that deleting, going to the home and end, and even moving around with the arrow keys is rather a pain. In vi this is already basically solved cross-platformly.
(Originally written sometime before 2006-10-27.)
Sean B. Palmer, 2006-11-21