[HN Gopher] Using a Piece of Paper as a Display Terminal - Ed vs...
___________________________________________________________________
Using a Piece of Paper as a Display Terminal - Ed vs. Vim
Author : rhabarba
Score : 60 points
Date : 2020-10-08 05:45 UTC (17 hours ago)
(HTM) web link (blog.robertelder.org)
(TXT) w3m dump (blog.robertelder.org)
| lqet wrote:
| > 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
| segfaultbuserr wrote:
| > 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 _n_ th read, I think "5.89824e37" is the funniest part of
| the joke.
| Uehreka wrote:
| 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."
| NateEag wrote:
| I'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
|
| It's one of the best things on the Internet, IMO.
| russh wrote:
| 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.
| coldpie wrote:
| Along 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=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.
| not2b wrote:
| 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.
| ansible wrote:
| 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.
| macjohnmcc wrote:
| 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!
| cultus wrote:
| 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.
| aap_ wrote:
| The museum has closed for the moment. Its future is uncertain.
| rsecora wrote:
| As 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
| cogburnd02 wrote:
| Yeah older ttys were basically a typewriter with a connection to
| a computer between the keys and the printing mechanism
|
| https://youtu.be/CRdma6NINIw
| kps wrote:
| `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.
| smitty1e wrote:
| I've always pronounced TTY as 'teletype'.
| dig1 wrote:
| 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.
| [deleted]
| moonchild wrote:
| > The only editor you can easily script, the same way as you
| type in it
|
| Easy enough to do with vim -c.
| segfaultbuserr wrote:
| 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_.
|
| 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._
| gumby wrote:
| 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 _2400_ baud
| 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 wrote:
| > sort of like a networked channel controller on steroids.
|
| Huh?
| theg5prank wrote:
| https://en.wikipedia.org/wiki/Channel_I/O
| nitrogen wrote:
| This 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
| gumby wrote:
| The wikipedia entry for channel controller is literally the
| first response when I type "channel controller" to
| duckduckgo.
| saagarjha wrote:
| 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.
| jpbpdx wrote:
| 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.
| jolmg wrote:
| > 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.
| ansible wrote:
| 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.
| greggyb wrote:
| > 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.
| dllthomas wrote:
| 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.
| rsecora wrote:
| Quick automated scripted editing, in the same way you will use
| sed.
| jolmg wrote:
| > 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 wrote:
| 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. :-)
| bitwize wrote:
| Ed is the standard text editor.
|
| Ed, man! !man ed
| robaato wrote:
| 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...
| pmoriarty wrote:
| _" 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_ wrote:
| 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.
___________________________________________________________________
(page generated 2020-10-08 23:01 UTC)