C70:editor-people (06/10/82)
>From Goldberg@RUTGERS Thu Jun 10 01:07:58 1982
Welcome to the world of reality. If this were a perfect world, hacks
such as XON/XOFF would not be needed. A recent article in BYTE
describes the RS232 non-standard and how computer devices can't
use it because the pin definitions do not have agreed upon semantics.
Modem protocols do not seem to allow *transmission* of states such
as "the timesharing computer is ready to receive another character"
except through character codes.
Of course, the implication that one therefore cannot put ^S's or ^Q's
in the file is wrong. However, one cannot put them there by typing a
key on the terminal that sends a ^S or ^Q if the terminal will send
a ^S or ^Q to indicate something else. The terminal could be
configured to send some special multicharacter sequence when the
user types a true ^S/^Q on the keyboard, or the user could enter
these codes using the same kind of quoting mechanism used to enter
a ^C on TOPS20. For a brief window, the editor would turn off monitor
level XON/XOFF and read whatever character the user typed.
To those who do not understand why some terminals need this protocol,
I agree that some that need it for 9600 baud could be reprogrammed
to run faster and not need it, but what if the screen sizes increase
to 132 by 120, etc.? Or baud rates go up to 19,200? And what about
letter quality printers that can't possibly keep up?
Boycotting devices that use XON/XOFF seems like a misinformed approach
to this problem.
Bob
-------C70:editor-people (06/11/82)
>From BILLW@SRI-KL Fri Jun 11 00:28:23 1982
A reasonable editor/operating system combinations shouldnt have
too much trouble distinguishing between a ^Q/^S typed by the
user from one gernerated by the terminal. After all, it should
know when characters are being output, and when the terminal is
just sitting there waiting for the user to type something. I
thought that Gossling EMACS (for vax unix) already did this kind
of thing...
Bill WestfieldC70:editor-people (06/12/82)
>From z@CCA-UNIX Sat Jun 12 01:08:50 1982
The editor can't always tell if the ^S/^Q was typed by the terminal or
the user. For example, suppose I'm typing ahead and hit a ^S while
the terminal is redisplaying - this looks just the same as the terminal
trying to stop further output.C70:editor-people (06/15/82)
>From COMSAT.SoftArts@MIT-MULTICS Tue Jun 15 00:19:14 1982
Use of padding instead of ^S/^Q implies that the host can fully
emulate the timings of an arbitrary complex terminal, across all
versions of software releases for that terminal including all special
cases and optimizations of the terminal and independent of any other
processing (such as keyboard handling) that the terminal might do and
through any networks that might be used and might have contention and
provide optimal highly tuned performance for all this.
While ^S/^Q is lousy, it is what we are stuck with for the moment.