[comp.emacs] How we could have made flow control livable

warren@ihwpt.ATT.COM (warren montgomery) (06/22/87)

I am not a fan of ^S/^Q, but flow control is a necessary evil for
some applications of terminals.  First, for all of those arguing
about whether flow control can be avoided when scrolling through a
megabyte file, realize that there are many ways to use a terminal. 
If you really want to watch a megabyte flash before your eyes or
have it spew onto your 10cps printer, you can't avoid flow control. 
If, however, you just want to re-paint a screen, like emacs and most
other applications do, the number of characters that the terminal
needs to buffer to avoid flow control is bounded by the number of
characters that fit on the screen (plus a bit for type ahead
situations).  This is what I think terminal manufacturers have
little excuse for not providing for.  The terminal should be able to
keep up with the line speed for long enough that a page can be
blasted out without flow control.

The place ^S/^Q really gets me, though, is on inter-machine links
(cu, rlogin, dkcu, etc.)  All of these on my system at least either
need ^S/^Q to function, or are broken in some way so that ^S/^Q is
permanently stuck on.  The unix TTY driver could have been written
in a way to make this all much easier, if it had allowed ^S and ^Q
to be escaped by preceeding them with backslash.  Then, over an
inter-machine link, if you turn off flow control locally, it passes
your ^S/^Q's through with backslashes in front and they go straight
to your remote emacs, while still allowing the two machines to use
^S/^Q internally.  (yes, you have to synchronize input and output to
the point where the receive half doesn't generate a ^S after a
backslash, but this isn't tough).  The backslash escape would also
allow emacsers to type these things from a terminal that needs ^S/^Q
if they really want to, provided that they are a bit careful about
typing backslashes during output.

-- 

Warren Montgomery,  ihesa!warren

jr@LF-SERVER-2.BBN.COM (John Robinson) (06/25/87)

>> The unix TTY driver could have been written
>> in a way to make this all much easier, if it had allowed ^S and ^Q
>> to be escaped by preceeding them with backslash.

Or map ^S to \023 and ^Q to \021 (and \ to \\ maybe).  That avoids
having to synchronize the two directions (impossible if anyting
"intelligent" out there wants to interpose flow control anyway).  Or
have a "controlify-following" or maybe "flip-control-bit-on-following"
escape/prefix.  The latter was a clever suggestion in a protocol
proposal I saw from Hayes for doing reliable transmission over phone
lines.  It was packet-oriented (too hard for Unix tty and "dumb"
terminals probably), but the flow-control didn't reserve any
characters (i.e. it was transparent to any 8-bit character coding you
wanted to send).

But this is the emacs list ... which brings me to: I remember from my
TENEX/ITS/Tops20 days that there used to be a one-character
"control-prefix" character in original EMACS that read the next
character and did the obvious thing.  Maybe this would help the
keyboard-remap question that has been popping up of late.  Left as an
exercise for the reader.

In ol' EMACS, it was control-Z (actually, I think it started out as
^C, but DEC operating systems really wanted that to be
interrupt-process so RMS relented).  ^Z-s was the same as ^S.  ^Z is
pretty easy to type.  But then job-control Unix wants ^Z for pausing a
process, which is its usual default binding, but that could be ^Z-^Z
or some such cleverness.

/jr