drw@cullvax.UUCP (Dale Worley) (06/18/87)
(Note: RLK, your messages start with: From: rlk@.COM (Robert Krawitz), which is probably wrong.) Well, it's all well and good to talk about buffering as a way to reduce flow control, but I can't see any way to get the guaranteed-no-flow-control rate any better than the slowest operation the terminal supports. For example, if it takes 18ms to scroll, and the computer sends 10^6 ^J's, if you permit them to be sent much faster than one character per 18ms, you're going to have to buffer 1 MB of data. Ugh! Can you imagine how long it will take to get ^C to stop output? Now, if you can load-shed, say by performing a several-line scroll in the same time as a one-line scroll (bit-map displays are like this), then you can effectively just keep an up-to-date screen image in memory and update the real screen as time permits. Ultimately, ^S/^Q flow control is a quite reasonable concept if (1) the host software is assumed to not understand screen sizes, and so when you 'cat foo', you want to be able to stop the output and examine it (VT100 'smooth scroll' is a variant of this), and (2) there is no reliable 'extra' data path available. It's only recently when people have started using Emacs as a total user environment that (1) has been avoided in a significant fraction of common usage. No one uses a glass tty at 9600 baud! Dale -- Dale Worley Cullinet Software ARPA: cullvax!drw@eddie.mit.edu UUCP: ...!seismo!harvard!mit-eddie!cullvax!drw "President Nixon has just lowered the speed of light to 55 mph. At what speed can 2 colliding VW's of mass m = (number) produce a 3rd VW?"