3 ms·

Why not? Text mode is still well supported

gumby 5y ago
Slow mode was designed to minimse (which included delaying) display updating. So you could type a bunch and only when you stopped typing would you see the display update to the final state -- intermediate states weren't rendered (so you could type ab<delete><delete>cd and only after you stoped typing would you see "cd" Printing terminal mode with similar in that it showed only the line you were on, and, IIRC, optionally the line above or below. This worked pretty well in Emacs where search is extremely lightweight and is (for most people at least) the primary cursor movement tool. Of course deletion couldn't display properly so you would get a marker on the screen (#?) to indicate, and then ^L would draw the then current copy of the line. You could write this support today, and perhaps someone has, but I wonder if it could possibly be worth it. This same reason is why the unix terminal driver by default starts up with # as the delete character command and @ deleted the whole line. That line discipline dates back to Multics, which had more efficient I/O as the Multics hardware had channel controllers (all our I/O is done with channel controllers these days, though we don't call them that). Actually, speaking of channel controllers: Emacs had a third mode: if you used the SUPDUP protocol (stood for super duper: roc 739, 746, 749) a bunch of the IO and screen update was done by your local host, not the remote machine on which you were running Emacs (or whatever). It implemented an abstract display and could even interpret a few commands to display the local buffer properly like a souped-up channel controller! This all predated Unix on the arpanet so later approaches went in a different direction. But remember this was back when you could have dozens of people using networked computers with clock speeds in the hundreds of kilohertz or less, back before the cross continent backbone was upgraded to ~56 Kbps.

Slow mode was designed to minimse (which included delaying) display updating. So you could type a bunch and only when you stopped typing would you see the display update to the final state -- intermediate states weren't rendered (so you could type ab<delete><delete>cd and only after you stoped typing would you see "cd" Printing terminal mode with similar in that it showed only the line you were on, and, IIRC, optionally the line above or below. This worked pretty well in Emacs where search is extremely lightweight and is (for most people at least) the primary cursor movement tool. Of course deletion couldn't display properly so you would get a marker on the screen (#?) to indicate, and then ^L would draw the then current copy of the line. You could write this support today, and perhaps someone has, but I wonder if it could possibly be worth it. This same reason is why the unix terminal driver by default starts up with # as the delete character command and @ deleted the whole line. That line discipline dates back to Multics, which had more efficient I/O as the Multics hardware had channel controllers (all our I/O is done with channel controllers these days, though we don't call them that). Actually, speaking of channel controllers: Emacs had a third mode: if you used the SUPDUP protocol (stood for super duper: roc 739, 746, 749) a bunch of the IO and screen update was done by your local host, not the remote machine on which you were running Emacs (or whatever). It implemented an abstract display and could even interpret a few commands to display the local buffer properly like a souped-up channel controller! This all predated Unix on the arpanet so later approaches went in a different direction. But remember this was back when you could have dozens of people using networked computers with clock speeds in the hundreds of kilohertz or less, back before the cross continent backbone was upgraded to ~56 Kbps.