mark (04/13/83)
Bj's kludge probably didn't work well because of typeahead - people like
to type things like ^Q while the editor hasn't settled down from the
previous command yet.
I caution against using the LINTRUP bit he mentions (it's documented briefly
in tty(4) in the 4.1BSD manual) because it went away in 4.2. It never did
really work very well - you'd get an interrupt, read a character, then
while reading the character the user would type another character, you'd
get another interrupt, read the 2nd char, process the 2nd char, return to
process the 1st char. Result: chars are received and processed out of order.
You also have to be real careful not to get out of sync - sometimes you get
more or fewer interrupts than there are characters, and get into a state where
you type a character and the 3rd previous character echoes. Each interrupt
routine has to read until the read fails.
You can't use DTR flow control over a dialup - there is just no comparable
signal over the phone line.
So really there are three choices:
(1) Use XON/XOFF and move ^S and ^Q elsewhere.
(2) Use nulls to pad. This is not hard - termcap does all the calculating
for you - but you have to make worst case assumptions about the terminal,
and since most terminals have buffers now, you'll get much worse
performance than you would with XON/XOFF.
(3) Develop some kind of packet protocol or character stuffing to use over
the phone line to make XON/XOFF work and still be transparent. This
only works if you have a terminal that supports this (I've never seen
one) or that you can program yourself (e.g. a workstation, a personal
computer, or if you can burn your own proms.)
Of course, there are the other options that are crazy, e.g. use a different
editor (vi doesn't have this problem) or restrict yourself to terminals that
don't need any flow control (the adm31 is the only one I have ever seen that
NEVER needs flow control) or only run at a slow baud rate.