Using a Piece of Paper as a Display Terminal – Ed vs. Vim
blog.robertelder.org
blog.robertelder.org
Even after display terminals became more commonplace in the late 70s, the connections were not always particularly fast (110 baud was still fairly common though 300 baud was most prevalent by then. Some people had lightning-fast 1200 or even 2400baud terminals, though in some cases, like at Stanford, still slow upload, like asymmetric home connections today. So EMACS had some support for "slow terminal" mode in which display updating was intermittent rather than every time you typed a character.
These modes worked if you knew what was already in your buffer and were used to typing without looking at the keyboard and screen all the time.
The arpanet was also pretty slow by current standards so there was a remote login protocol called SUPDUP (as in the Super Duper display protocol) that (to simplify massively) did display updating locally, sort of like a networked channel controller on steroids.
None of this survived into GNU emacs as by then the networks, at least the local networks, were better.
Huh?
I did find this previous HN comment, also by gumby, on a similar article: https://news.ycombinator.com/item?id=14408209
Basically it’s the forebear of the “switch”
The computer connected to the terminals treated CRT and paper based terminals in the same manner and wrote characters one by one; a line feed caused the paper or the 24 lines displayed on the CRT to scroll up a line.
Because the terminals operated no faster than 30 characters per second (300 baud) it was most practical to keep a few lines of code in one's head while entering a sequence of editing instructions and only ever so often have the editor "print" a few lines in the region one was working on the screen to see how things were going.
Even though this sounds quite primitive and painful, it was a big improvement over using a keypunch machine to program on punch cards.
I have a couple of ideas:
A large e-Ink display connected to a Raspberry Pi
A Boox tablet
Are there any others I should consider for this use case? My biggest concern is refresh rate. I usually edit with vim. Greyscale syntax highlighting would be a plus.
I use the boox outside to read documents and then go back inside to code.
https://goodereader.com/blog/reviews/dasung-paperlike-3-hd-r...
I think I heard someone found an exploit on the most recent one. If the pinephone didn't exist that would be tempting (and it kind of still is, having a small portable Linux machine with a week of battery life was nice even if it could only hold 4Gb.)
https://www.waveshare.com/product/displays/e-paper/epaper-1....
I'll get mine in a month or two and plan to try out how it works as a second screen for programing and writing.
[0]: https://github.com/reHackable/awesome-reMarkable#screen-shar...
Essentially, think of using your laptop, but instead of looking at a monitor you're reading the output from a printer. So if you type `ls`, you see the directory listing being literally printed out on a dot-matrix printer. Naturally the only way of text editing is with a line EDitor, which lets you edit text one command at a time.
When trying to use ed on a video terminal, it obviously looks wasteful. But that's because it was designed before video terminals were a thing. Kind of like using a modern day graphics card to play pong.
here is a video illustrating using a teletype:
* Couple of KBs, you can't beat that. You can put it almost everywhere.
* Runs with whatever terminal you have to use. Unknown or broken termcap, no problem. Even works inside Emacs eshell.
* Still unbeatable with terrible connections. Try that with vi/vim, and you'll cry, even without colors.
* Gives you "focused editing" without having to look at the whole file. Just like Ken Thompson said. For example, to read .bashrc ignoring comments, just use "g/^[^#]/n".
* The only editor you can easily script, the same way as you type in it. That is why we have "script" command.
* Very easy to print commands (as the author showed) and give students as "howto" to edit something. Easy to follow and no ambiguities.
Easy enough to do with vim -c.
# ssh foo
Blah blah something nasty blah blah ssh rsa key known_hosts:29
# ed .ssh/known_hosts
123456
29d
123454
w
q
# ssh foohttps://www.youtube.com/watch?v=2XLZ4Z8LpEE
It's one of the best things on the Internet, IMO.
It starts with using the front panel switches to load a program into an Altair 8800 and progresses into loading programs from external sources including audio cassette and paper tape; loading programs from a ROM; loading and using an OS; and using a paper terminal for output.
ED(1) UNIX Programmer's Manual
ED(1)
NAME
ed - text editor
SYNOPSIS
ed [ - ] [ -x ] [ name ]
DESCRIPTION
Ed is the standard text editor
Ken Thompson
find somedir -name "*.md" | while read f ; do
ed $f <<__DONE
...whatever magic you need
w
__DONE
done
Original `vi` also has ‘open mode’ for printing terminals and glass ttys — like a series of one-line windows, where every vertical motion starts a new line. None of the popular clones implement it.
-rwxr-xr-x 1 root 24 Oct 29 1929 /bin/ed
-rwxr-xr-t 4 root 1310720 Jan 1 1970 /usr/ucb/vi
-rwxr-xr-x 1 root 5.89824e37 Oct 22 1990 /usr/bin/emacs
On my nth read, I think "5.89824e37" is the funniest part of the joke.
It's definitely my favorite part of the museum. It really amazes me how much was possible on such limited hardware.
Has anyone come up with an ed with the advantages of a modern screen, so it shows the full file on the side but you can still run ed commands on it?
Edit: I should have expected getting "vi" as an answer, although I can't fault all the commenters below :P I was thinking of something a little less different, like literally just a command prompt on the bottom and a pane above centered on the line you just operated on.
Unless I misunderstood you, it's called Vi(m).
> I am curious if anyone uses ed as their editor of choice these days, assuming an actual screen and such of course. If so, why? Muscle memory?
If I'm on a machine where the choices of editor are either ed or nano, I prefer ed.
Also, if I want to do some text processing on a bunch of files and it's simpler to do it with an ed script than with sed or awk, I'll use ed. It has happened.
If I remember right, I wanted to edit some upper lines when some lower lines matched some regex for a bunch of files. It ended up being an ed command like 'g/foo/?bar?s/baz/qux/'. Doing something like that with sed or awk gets more complicated.
> Edit: ... I was thinking of something a little less different, like literally just a command prompt on the bottom and a pane above centered on the line you just operated on.
If you stick to command-mode, that's pretty much what vi and vim are. You could run this in vim:
:cmap <enter> <enter>:
It's called vi or vim.
ed is also nice if you otherwise want to remain in the cognitive context of the stuff that's already on your terminal. Sometimes that blink that occurs when blanking and replacing your primary visual field can be useful, sometimes not.
ed is a line editor. You know how lots of people like vi because it is so much easier to place the cursor where you want it? ed doesn't even have a cursor. This can be faster in some (rare) cases, but moreover it forces me to think about the file as a structure of code while visual editors generally allow me to be lazy and think about the file as an array of characters.
Finally, ed is great when you know what you want to read and/or write. It is like grep but with the ability to base the next command off the previous one, or to go result by result. It is like editing in place with sed but with far less hassle/risk for one-off changes. If you'd be doing the same thing in vi, you save the trouble of typing ':'.
Along those lines, ed becomes nicer for one-off edits when you compile it with PCRE support rather than the antique, POSIX-standard regular expression format.
For reviewing files on the side, open up another terminal window, read a named pipe, and write to that pipe from ed. Do this with three or four different terminals and you've got a fairly complex set of indirect buffers that can be updated with a bare minimum of tooling.
I wouldn't want to use only ed but I'd miss it if it went away.
Indeed, the value of the terminal scroll-back buffer. One of the reasons I prefer CLI over TUI/GUI sometimes is that the terminal acts like a chat window with my computer. With programs like ed, you can review the conversation you've had with it.
I can quickly switch between multiple terminals (which I label with names like 'edit', 'build', 'run', and 'console'). I've experimented with splitting a single window into multiple panes (GNU screen has slightly clunky support for this), but overall haven't found that to be as useful. I use the vim keys for viewing / copying the terminal window history as well as command-line history.
For a long time I've eschewed using multiple tabs in Gnome Terminal, but I've started using those as well. Instead of having multiple terminal windows for different hosts, I just use different tabs, and switch between them via Ctrl-PageUp and Ctrl-PageDown. Another option there is to use another level of GNU screen with a different hotkey, but perhaps down that path lies madness.
I use ed extensively. At least I have EDITOR=ed by default. This started mostly as an experiment to "stretch my mind," but over time ed grew on me.
It changes the way you think about text editing in the same way that Haskell or Clojure or Forth change the way you think about programming.
Ed isn't particularly interesting at first. It feels klunky and editing is slow. But a similar statement could be said about almost any musical instrument. It only really becomes interesting once you have interalized the mechanics of using your tool.
Personally, I find myself organizing text differently than when I use vim. With the latter, I definitely want my code to be visually appealing, while with ed I want it to be appealing to edit.
Definitely encourage you to give it a good, solid try if you're interested.
Of note, there is a mildly famous APL programmer, Aaron Hsu, that claims to like line editors. He wrote his own actually: https://github.com/arcfide/ALE.
That's pretty much what vi (or at least it's ancestors) was. Modern vim is very different to the original implementation but vi was intended to be a visual ed. Hence it's name: VIsual mode.
Even my dorm had a Lear Siegler ADM 3 in the basement for students to use, right next to a Wang word processor.
I often hung out in the Engineering terminal rooms though, because they had the nicer Wyse terminals. Well, until senior year when CS installed some black & white X terminals for general use, which connected to a Sequent Symmetry 80386 system. That was really kick-ass at the time.
When I visited ISU a couple years previously, they were still using paper tape for storage on one of their PDP-11s. So I just missed that era too, we were using 9-track for file backups.
Sadly, I can't afford an ASR-33...
https://retrocomputing.stackexchange.com/questions/5341/how-...
> Using a line-based editor isn't that hard. For one, yes, real programmers (as we all were back then) do remember their lines. A program grows in your head; the screen is just to dump the result, isn't it? How are you able to understand your own program if you can't visualize it in the first place?
> [...] Of course, these were all 'super specialists' and way better than anything we were ... the usual game. And as so often they came up with the same questions, why not use a high level language, a standard DBS and so on. The usual crap. Seriously, with an application of that size, writing such components is just a minor add on. Eventually needing less code than using a standard interface requires - not to mention being faster because being tailored exactly to our needs.
> Anyway, let's go for the story. One of these 'specialists', lets call him Mr. W., claimed that no one can oversee such a large codebase, not even partially. Heck, no one can even remember all code written by himself in 5 or more years. Ha! That was a claim that I couldn't let stand uncontested, so one word yielded the next. Bottom line: we agreed for a bet, one beer, that I will be able (he said not able) to identify source name when presented a 10 line snippet, from random programs I did within the existing codebase. We agreed on 10 examples. Date was set the next morning.
> Morning came, I didn't prepare nothing, but he came up with a stack of paper and a case of beer. I guess his intention was to show how much I didn't gain by presenting every fail with a bottle. Also, he was so generous as to make the snippets a whole page each. I didn't really need that. I named not only each routine he handed me, but also which module it belonged to, what's the purpose, some workings, why variables are named the way they are, some caller or what was to be found on the pages before or after. Further, I also named the original programer, as he inserted a few pages from programs I didn't write and identified a piece of code that was no longer used, told why and what has replaced it - he pulled it form a very old version :))
> The whole case of beer, bottle by bottle, changed sides :))
> The same time Mr. W. became more and more quiet. Needless to say that there was no further argument about readability of code or the ability to handle a large code base. Sure, there was still the database fight, but that's a different story.
Ed, man! !man ed