Stupid ideas part 469: line editor
Interesting quote in this article about Unix history:
By the way, ‘em’ stands for ‘editor for mortals’ – I christened it that after Ken Thompson visited our lab at QMC while I was developing it and said something like: “yeah, I’ve seen editors like that, but I don’t feel a need for them, I don’t want to see the state of the file when I’m editing”.
So I was wondering… would a line editor still be feasible today? The obvious answer is “no”, of course. Nobody uses them anymore, as far as I can tell (at least not interactively)… as a matter of fact, quite a few people seem to think that even an editor isn’t good enough to edit code anymore, they want IDEs (whatever that means — it seems to depend on the speaker).
However, I have a tendency to look for non-obvious answers. :-) Question is, why did Ken Thompson say this? Notice that this quote is from around 1975, when line editors were pretty much the default (or so I understand; I was only 2 years old at the time :-). I assume that Ken has moved on since then. Nevertheless, one can wonder, did he say that simply because he was used to line editors and didn’t see the need for anything “fancier”; or is it because line editors have certain qualities not found in other editors?
I have never really used line editors myself. In 1991 my first PC came with edlin, which seemed prehistorical even then. Heck, the C64 had a more powerful environment to code in! But I have often wondered what it would be like to use them. Because of all their restrictions, they force you to focus on only the text (or code) you are interested in. This would make for a very different editing experience than jumping through the whole documents using cursor and PgUp/PgDn/Home/End and friends.
Many questions arise:
- Would modern-day users be able to get used to it? (I have power users and hackers in mind here, people who regularly use a command line of some sort.)
- How would you get around the document (efficiently)?
- How would you copy & paste?
- How would you delete or replace stuff and be confident that it didn’t overwrite the wrong thing?
- Would it be possible to add modern features like code completion, svn integration, etc, and what would it look like?
- What would be the macro/automation capabilities of such an editor? (Probably quite powerful)
Maybe this would make for an interesting (although not necessarily practical) side project. I’m especially interested in finding out what it “feels” like to use such an editor, if it’s still usable nowadays, if it has benefits of any kind over regular editors, and if/how modern features can be added to it.
John Cowan said,
January 21, 2009 @ 7:38 pm
YES YES YES YES YES YES!
I am an “ex” troglodyte. I use “ex” for all my editing: code, email, HTML, you name it. I could (and on rare occasions actually do) use “ed”, but “ex” adds a few convenience features to “ed” that I find extremely useful. (Edlin is a dreadful turkey.)
1) Am I used to it? After thirty years of professional programming, I have never bothered to get used to anything else.
2) If I’m scrolling, repeated “z” commands; otherwise by searching.
3) I run “ex” in a terminal window, so I do select, copy (not cut), and paste using ordinary X/Gnome mechanisms. Of course, I only paste after giving an a(ppend), i(nsert), or c(hange) command.
4) I use z or p(rint) to display a stretch, and then /xxxx/,/yyyy/d(elete) or /xxxx/,/yyyy/c(hange) to delete or replace lines of text. Intra-line changes, as well as global search and replace, use the s(ubstitute)/foo/bar/ command.
5) My version of code completion is touch-typing. I do svn things in a shell window.
6) No macros. I don’t use “ex” to edit text, I just *edit text*. I no more think about what commands I am using, normally, than I think about what fingers I use to press keys (I’m a touch-typist). So I don’t want a configurable editor, I want a stable editor.
One problem with using “ex” is that many systems provide Vim as their “vi”, and Vim releases < 7.0 are crappy “ex” implementations. Nvi and Heritage Toolkit Vi, however, are excellent. I install one or the other of these; in particular, Heritage Toolkit can be installed into your home directory on systems where you don’t have root, although there is a very slight degradation of function.
However, if I were starting off now, I’d probably use Sam rather than “ex”; it provides a smooth integration of mouse-editable display windows and a command-line editor closely related to “ex” but with some improvements in generality and flexibiity.
See http://catb.org/~esr/writings/taoup/html/ch13s02.html for an objective writeup of the ed/ex, vi, Sam, emacs, and Acme/Wily editors; the followup at http://catb.org/~esr/writings/taoup/html/ch13s03.html talks about the strengths and weaknesses of each.
John said,
January 22, 2009 @ 3:44 am
When I first create a simple text file, it will often be with ed. Good old ed. vi and friends clear the whole screen, making it difficult to copy paste with the mouse.
Hans Nowak said,
January 26, 2009 @ 1:51 pm
@JC: I am curious how well a line editor works for code. I’d expect that editing Lisp or Python code would be cumbersome, as it’s easier to make mistakes in matching parentheses or indentation. Maybe less so when you add it, but what about when you go back and edit it?
Eric said,
February 4, 2009 @ 2:28 pm
I’ve used ed (often with -p: ) while running under script . Full-screen editors do nasty stuff to the transcript, making it difficult to really see what happened. It took a bit to learn its commands, but they’re enough to satisfy navigation, copy/paste, deletion/replacement, and even viewing chunks of the file. I did some basic shell scripting like that without problem, but haven’t tried any larger projects.
Sam Phillips said,
February 4, 2009 @ 3:26 pm
I don’t use line editors often. But from the perspective of implementing an screen style editor (like vi/emacs), starting out with a line editor for the core is very useful in understanding how editing really works.
My possibly offtopic 0.02.