After reading this article, I actually get why ed was the standard text editor. And it almost makes “Ed, man! !man ed” feel like a cheap shot. Like someone today looking at one of the first automobiles, missing the point and being like “Oh you should totally drive this, it has tons of horsepower.”
I actually think it's something I hate as well, but I never tried going without. It's distracting, sometimes I drift just because lines are not aesthetically pleasing, and I don't really want to stretch concise python lines to compensate. Ed might just be the solution.
This was actually a nice thing about WordPerfect in a terminal window instead of Word on a Windows box back in the day. With just plain text and markup indicators (yes, TeX was also an option for this kind of thing) you focused on the content not on "oh, I need to rephrase that so it wraps better."
EMACS used to have a printing terminal mode -- which shouldn't be surprising when you consider that it was written in TECO, an editor for printing terminals. In fact EMACS evolved because a display mode (^R mode) had been added to TECO, which opened up new possibilities.
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.
Wikipedia's built-in search is always difficult to use, especially, its "Did you mean..." is useless for correcting anything but basic typos. To be fair, it's a simple function anyway, there's no PageRank or NLP. Using site:wikipedia.org on a real search engine works better.
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.
The Model 23 Teletype connected to my Netronics ELF II was so loud I was only allowed to use it during the day.
It was slow, noisy and smelled like a mixture light Oil and electrical sparks but you could play Tiny Star Trek on it. At least until sundown, or it ran out of paper.
Yes, I'm old enough to have done editing on printing terminals, when I was in college; I liked TECO much better than ed in those days, though. You could chain a bunch of commands together to minimize the amount of paper you used up, but it took practice and a good memory.
I'm old, but I'm just young enough to have missed that era. I think they still had some paper terminals somewhere, not sure.
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.
There were some relatively dumb CRT terminals available, but not enough. It still beat punch cards, which I sometimes had to deal with when I was just starting.
There was still a punch card reader in the terminal room of Math/Sci, but I had never seen someone use it.
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.
ed is still my daily driver when I need to edit stuff quickly, and here are a couple of reasons I'm keeping it in my toolbox:
* 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.
It would be great if someone could demo their workflow with ed, to give people an idea of how it is. For now, I think I much prefer to see context lines when I’m editing
Funny, I used to say the same thing about vi (I normally use emacs, but it was much quicker to open known_hosts with vim, type `29GddESC:wq!`). Though a few years ago ssh started to output a command to run, so I just copy-paste that now.
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?
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.
> 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?
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>:
to re-enter command-mode automatically as soon as you leave it.
As to your second question: Yes, Bill Joy did that in 1976 when he added a visual mode to his line editor ex that was itself based on ed. The mode was called vi (for "visual") and updated the screen as you typed ex commands preceded by a colon. All vi descendants have this feature, including Vim. :-)
ed is great when you want to make a quick edit while reviewing what's above the current line in the terminal. Spot a problem, edit a file, and write a commit message while looking at the original problem, the solution, and the steps you took to get there.
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.
> 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.
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.
For me, a lot of those use cases are covered by GNU screen.
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've been meaning to try making a headless ed, that pushes commands out to the shell. It's like 30th down my list of "I should try this" at this point, though.
> 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?
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.
> 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.
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.
I took an off campus programming course when I was in High School in the early 1980's. There was only a single terminal that was CRT based in the lab the rest were TTY's. Slow, noisy and a huge waste of paper. We all tried to get in early to get on the single VT100 monitor!
> Of course, on the system I administrate, vi is symlinked to ed. Emacs has been replaced by a shell script which 1) Generates a syslog message at level LOG_EMERG; 2) reduces the user's disk quota by 100K; and 3) RUNS ED!!!!!! [0]
I did Computer Science at Edinburgh in the early '80s.
While there were VDUs around, there weren't enough - especially at assignment crunch time. Thus sometimes the only terminal available might be a teletype printer. So Ed was the only option! While not appropriate for major edits, it could allow you to complete some final tweaks...
If anyone finds themselves in Seattle after the pandemic, the Living Computer Museum has a real live paper terminal connected to a mainframe running an early Unix (iirc) that you can actually use.
It's definitely my favorite part of the museum. It really amazes me how much was possible on such limited hardware.
`ex` (i.e. vi's ex mode) is a better comparison than `ed`.
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.
Recommended reading: How did people use ed? from Retrocomputing Stack Exchange, the answer by Raffzahn also includes an old-school programming story, How Real Programmers Remember Code.
> 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.
To really understand how ed was useful, it's eye-opening to see exactly what life was like before video terminals.
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.
Wow, that is a fascinating video and such an inspiring spirit of hacking. I'd love to learn more about the electrical engineering side of computer science to be able to do similar experiments.
I used to write programs using TECO, a character oriented editor, while at grad school around 1975. I used "dumb" CRT based terminals and occasionally fan-fold paper terminals with TECO. TECO was quite powerful and had a macro system that allowed macros to be enter and employed to perform edits on the underlying file. Like vim-golf, it was possible with a few commands to do things like reverse the order of the lines of a file.
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.
On the note of terminal displays, I've been looking for a good e-Ink tablet that runs either Ubuntu Linux, or Android with access to the Play Store, and has a decent enough refresh rate so I could run an ssh client and code on it from time to time with a Bluetooth keyboard for eye strain relief, and for coding outdoors in full sun.
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 have a boox, I think it would work fine for a linear text, but ssh would be a bit hard. you could type commands but a screen scroll would be a 1/4 second or more to reload.
I use the boox outside to read documents and then go back inside to code.
Some of the older e-ink kindles are very easy to get a shell on and are just running a buildroot with X11. The downside is that storage is limited and the partition scheme the OS it ships with is nearly android levels of goofy (all user data has to go on a FAT.)
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.)
The community around the ReMarkable tablet has made a couple of solutions that makes it possible to use it as a second screen [0], and you could also replace the stock OS with Parabola-rM [1], a linux distro optimized for the ReMarkable. It's not cheap, but not terribly expensive either.
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.
Everyone who's serious about unix should learn a bit of ed. Ed + a here doc is really useful for some types of batch edits that you can't do using sed or perl -pi -e. Say you want to delete the line before the second line which starts "---" in the yaml frontmatter of 100 markdown files or swap the second and third line or whatever. Ed is your go-to.
find somedir -name "*.md" | while read f ; do
ed $f <<__DONE
...whatever magic you need
w
__DONE
done
I've done this kind of thing in shellscripts so many times. Recently it was in recovering my personal website by dumping out the wayback machine through lynx and retro-converting the text to markdown.
64 comments
[ 2.8 ms ] story [ 130 ms ] threadhttps://youtu.be/CRdma6NINIw
Ken Thompson
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”
https://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.
https://youtu.be/2XLZ4Z8LpEE?t=818
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.
* 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.
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:
to re-enter command-mode automatically as soon as you leave it.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.
https://en.wikipedia.org/wiki/Vi#History
[0] https://www.gnu.org/fun/jokes/ed-msg.html
On my nth read, I think "5.89824e37" is the funniest part of the joke.
Ed, man! !man ed
It's definitely my favorite part of the museum. It really amazes me how much was possible on such limited hardware.
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.
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.
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:
https://www.youtube.com/watch?v=2XLZ4Z8LpEE
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...
[1]: http://www.davisr.me/projects/parabola-rm/
Sadly, I can't afford an ASR-33...