vi is of course just a visual interface to ed, so they have the same commands, based on Multics qed.
I don't know about GNU Emacs, but the original Emacs (in TECO) had a "slow terminal" mode that did minimal updating, and a "printing terminal" mode that really just kept you up to date on what was going on around the cursor. It worked fine in a pinch. If I didn't want that I just used TECO, which his like using ed only more compact and of course programmable.
Speaking of slow terminal mode: the SUPDUP protocol (an early visual remote terminal protocol) had specific support for Emacs in it, so you could edit over the arpanet and get pretty good response. It repainted and managed the screen somewhat locally (like a channel controller but full duplex). It was handy even when the arpanet backbone was upgraded to a 56K line. I also used it from a KL-20 in Paris -> weird X.25 network -> MIT-Multics -> MIT-AI in the early pre-TCP 80s and it was bearable...just. SUPDUP made a huge positive difference.
A fun thing about this is that they joke that vi occupies 1310720 bytes on disk (which in context I think is meant to seem extremely, unreasonably large). But in 2017 my current vi binary (which also uses a lot of external files!) is 2923968 bytes, over twice the size of the imagined binary in the joke.
When I first heard that joke, I thought it meant "it forces you to swap frequently, even on a system with a (luxurious) 8 MB of main memory". But is it possible that it means "it forces you to swap frequently with its 8 MB binary image"?
I suppose it works either way, but I've always understood that to be about the size of emacs. Size meaning not just the binary, but that emacs is practically an OS unto itself.
vi is of course just a visual interface to ed, so they have the same commands, based on Multics qed.
I don't know about GNU Emacs, but the original Emacs (in TECO) had a "slow terminal" mode that did minimal updating, and a "printing terminal" mode that really just kept you up to date on what was going on around the cursor. It worked fine in a pinch. If I didn't want that I just used TECO, which his like using ed only more compact and of course programmable.
Speaking of slow terminal mode: the SUPDUP protocol (an early visual remote terminal protocol) had specific support for Emacs in it, so you could edit over the arpanet and get pretty good response. It repainted and managed the screen somewhat locally (like a channel controller but full duplex). It was handy even when the arpanet backbone was upgraded to a 56K line. I also used it from a KL-20 in Paris -> weird X.25 network -> MIT-Multics -> MIT-AI in the early pre-TCP 80s and it was bearable...just. SUPDUP made a huge positive difference.
(SUPDUP because it was a super duper protocol)
>I don't know about GNU Emacs, but the original Emacs (in TECO) had a "slow terminal" mode that did minimal updating
Sounds like this is baked into emacs pretty deep: https://www.facebook.com/notes/daniel-colascione/buttery-smo...
Officially, vi was the visual interface to ex, rather than ed, where ex was the extended version of ed.
A fun thing about this is that they joke that vi occupies 1310720 bytes on disk (which in context I think is meant to seem extremely, unreasonably large). But in 2017 my current vi binary (which also uses a lot of external files!) is 2923968 bytes, over twice the size of the imagined binary in the joke.
emacs = 8 Megs And Constantly Swapping
When I first heard that joke, I thought it meant "it forces you to swap frequently, even on a system with a (luxurious) 8 MB of main memory". But is it possible that it means "it forces you to swap frequently with its 8 MB binary image"?
I suppose it works either way, but I've always understood that to be about the size of emacs. Size meaning not just the binary, but that emacs is practically an OS unto itself.
Mentions edlin on DOS as well. I remember having to use that now and again.