8 ms·
Using a Piece of Paper as a Display Terminal – Ed vs. Vim
- smitty1e 6y agoI've always pronounced TTY as 'teletype'.
- Uehreka 6y agoAfter 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.”
- cogburnd02 6y agoYeah older ttys were basically a typewriter with a connection to a computer between the keys and the printing mechanism https://youtu.be/CRdma6NINIw https://youtu.be/CRdma6NINIw
- pmoriarty 6y ago"I've seen [visual] 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." Ken Thompson
- loa_in_ 6y agoI 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.
- fencepost 6y agoThis 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."
- gumby 6y agoEMACS 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.
- rusk 6y ago> sort of like a networked channel controller on steroids. Huh?
- nitrogen 6y agoThis is an unsearchable term. Even with the "arpanet" qualifier nothing relevant is returned. I did find this previous HN comment, also by gumby, on a similar article: https://news.ycombinator.com/item?id=14408209 https://news.ycombinator.com/item?id=14408209
- gumby 6y agoThe wikipedia entry for channel controller is literally the first response when I type "channel controller" to duckduckgo.
- 6y ago
- NateEag 6y agoI've linked this before, but this video of hooking a 1930s teletype up to a Linux computer is what made ed click for me. https://www.youtube.com/watch?v=2XLZ4Z8LpEE https://www.youtube.com/watch?v=2XLZ4Z8LpEE It's one of the best things on the Internet, IMO.
- coldpie 6y agoAlong the same lines, this series of videos is one of my favorite things I've run across recently: https://www.youtube.com/watch?v=suyiMfzmZKs&list=PLB3mwSROoJ4KLWM8KwK0cD1dhX35wILBj https://www.youtube.com/watch?v=suyiMfzmZKs&list=PLB3mwSROoJ... 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.
- russh 6y agoThe 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.
- lqet 6y agoVery cool indeed. The usage of ed starts here: https://youtu.be/2XLZ4Z8LpEE?t=818 https://youtu.be/2XLZ4Z8LpEE?t=818
- not2b 6y agoYes, 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.
- ansible 6y agoI'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.
- not2b 6y agoThere 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.
- ansible 6y agoThere 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.
- rhabarba 6y agoI still like TECO (or rather, TECOC) more than ed because it comes with a visual mode...
- dig1 6y agoed 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.
- moonchild 6y ago> The only editor you can easily script, the same way as you type in it Easy enough to do with vim -c.
- deleted 6y ago[deleted]
- kovek 6y agoIt 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
- Bluecobra 6y agoI use ed all the time when I need to quickly delete old SSH keys: # ssh foo Blah blah something nasty blah blah ssh rsa key known_hosts:29 # ed .ssh/known_hosts 123456 29d 123454 w q # ssh foo
- kwoff 6y agoFunny, 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.
- saagarjha 6y agoI 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.
- greggyb 6y ago> 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? It's called vi or vim.
- jolmg 6y ago> 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.
- mycl 6y agoAs 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. :-)
- macjohnmcc 6y agoI 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!
- lqet 6y ago> 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] [0] https://www.gnu.org/fun/jokes/ed-msg.html https://www.gnu.org/fun/jokes/ed-msg.html
- segfaultbuserr 6y ago> And ed doesn't waste space on my Timex Sinclair. Just look: -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 > I just want an EDitor!! Not a “viitor”. Not a “emacsitor”. Those aren't even WORDS!!!! On my nth read, I think "5.89824e37" is the funniest part of the joke.
- bitwize 6y agoEd is the standard text editor. Ed, man! !man ed
- robaato 6y agoI 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...
- cultus 6y agoIf 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.
- kps 6y ago`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.
- segfaultbuserr 6y agoRecommended 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. https://retrocomputing.stackexchange.com/questions/5341/how-did-people-use-ed 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.
- rsecora 6y agoAs the old joke says: ed is the standard text editor ED(1) UNIX Programmer's Manual ED(1) NAME ed - text editor SYNOPSIS ed [ - ] [ -x ] [ name ] DESCRIPTION Ed is the standard text editor https://www.gnu.org/fun/jokes/ed-msg.txt https://www.gnu.org/fun/jokes/ed-msg.txt
- Naac 6y agoTo 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. here is a video illustrating using a teletype: https://www.youtube.com/watch?v=2XLZ4Z8LpEE https://www.youtube.com/watch?v=2XLZ4Z8LpEE
- as_keyof_typeof 6y agoWow, 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.
- todd8 6y agoI 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.
- dheera 6y agoOn 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.
- grogenaut 6y agoI 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.
- jakecopp 6y agoDasung Paperlike eink monitor! Super expensive unfortunately but they're pretty amazing. https://goodereader.com/blog/reviews/dasung-paperlike-3-hd-review https://goodereader.com/blog/reviews/dasung-paperlike-3-hd-r...
- rbanffy 6y agoAll this makes me want to mod a 10 cps daisywheel typewriter into a serial terminal. Sadly, I can't afford an ASR-33...
- seanhunter 6y agoEveryone 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.