[kabdib]

I had Emacs running "okay-ish" on my 300 baud modem. I wrote a terminal emulator that implemented character and line insert and delete, and region scroll, which made Emacs screen refresh (borderline) tolerable.

Let's just say that it WAS tolerable considering that my alternative was to use punchcards. (Imagine long lines for punchcard machines in the basement of the CS building, which smelled of too many students and way too much fear, and waiting six hours for your program to run. Oh, and everything in uppercase...)

[a_e_k]

If memory serves, one of Emacs innovations was to decouple the display system from the editing system. The display would run asynchronously. If the display lagged due to a slow connection it would always be trying to show the most current state rather than strictly rendering the results of each edit operation, one by one. It also tried to minimize the terminal codes need to bring the display up to date.

I can't say I've ever used it on a 300 baud modem, but I have used it over a transcontinental SSH session on a crowded wifi connection and I've been thankful for it being designed to operate well under adverse conditions like that.

[ams6110]

Yes, I always assumed that was part of the motivation for "chunky" operations like forward/delete word, paragraph, etc. On a slow connection it made a big difference to be able to jump ahead by words, paragraphs, or "balanced expressions" rather than character-by-character. And VT100 terminals didn't have a mouse so there was no way to do something like click-drag to select a block of text.