gore@nucsrl.UUCP (Jacob Gore) (11/25/86)
In one of the installation documentation files for GNU Emacs, Richard Stallman
expresses his displeasure (to put it mildly) with the way DEC's terminals use
control-S and control-Q (XON/XOFF) for flow control. He says its a
"brain-damaged" design.
Could somebody tell me why that is the case? If that is the case? What would
be a better synchronization method? The only decent method I can think of
would use hardware handshaking...
Jacob Gore
Northwestern University, Computer Science Research Lab
{ihnp4,chinet}!nucsrl!gore
P.S. Sorry for posting this to two groups (comp.terminals and comp.emacs),
but Notes can't cross-post yet.henry@utzoo.UUCP (Henry Spencer) (11/30/86)
> In one of the installation documentation files for GNU Emacs, Richard Stallman > expresses his displeasure (to put it mildly) with the way DEC's terminals use > control-S and control-Q (XON/XOFF) for flow control. He says its a > "brain-damaged" design. > > Could somebody tell me why that is the case? If that is the case? One can debate whether the brain damage is in the terminals, or in Emacs and its authors. ASCII defines characters below ' ', plus DEL, as *control* characters, with various well-defined purposes. Many of those purposes are incompatible with treatment as if they were ordinary data characters, to be transmitted unchanged by communications hardware. Unfortunately, back in the days when communications hardware was dumb and control characters seldom got special treatment, the custom grew up of using such characters as commands to software. There are a lot of programs, e.g. screen editors like Emacs, where it is *very* handy to have characters which are not valid text and are interpreted as commands. This depends on such characters being transmitted unaltered. Alas, as hardware got smarter, some of the control characters started being used for their original purpose, to the great displeasure of people (like Stallman) who had (mis)appropriated them for other uses and found it difficult to give them up. Use of XON/XOFF is nearly universal in the industry now, by the way. DEC catalyzed this development but was not fundamentally responsible for it; the original protocol was established by the venerable ASR33. There is no truly fundamental incompatibility here, since there is no law saying that holding down CTRL while hitting S must send an XOFF character; it could just as easily send a multi-character escape sequence that would avoid characters with special meaning to the hardware while still getting the message through to the software. Unfortunately, terminals generally don't provide this as an option. > What would > be a better synchronization method? The only decent method I can think of > would use hardware handshaking... Hardware handshaking is a bad idea because it doesn't transmit well over networks or modems. The real solution is a better terminal protocol, perhaps packet-oriented. XON/XOFF not only irritates Emacs users, it also is not really a very good handshaking system -- it loses big when there are long delays in the communications links. What's needed is a "give me N more characters" protocol rather than a "stop right away, I'm full" protocol. To really work well, it would have to be standardized so that all terminals spoke the same protocol. Don't hold your breath waiting. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
csg@pyramid.UUCP (Carl S. Gutekunst) (12/03/86)
In article <7362@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: > What's needed is a "give me N more >characters" protocol rather than a "stop right away, I'm full" protocol. >To really work well, it would have to be standardized so that all terminals >spoke the same protocol. Don't hold your breath waiting. There was an alternative that never really caught on: ENQ/ACK handshake, where it was the responsibility of the host to send an ENQ every 'n' characters, and wait for the terminal to send an ACK. The oldest terminal I can remember using this was the HP 2640 series (which ain't that old). A number of other vendor's terminals and printers in the late 1970s also supported this handshake, but lately I've only seen a few printers that do. None of the standard UNIX tty drivers support ENQ/ACK; for that matter, I'm not aware of any OS/computer vendors besides HP and Burroughs that do, and Burroughs only does so to support HP2641 terminals on its online frontends. Of course, I'll bet that Gnumacs is already doing something special with ENQ <CTRL-E> and ACK <CTRL-F>.... <csg>
ron@brl-sem.ARPA (Ron Natalie <ron>) (12/05/86)
In article <1132@pyramid.UUCP>, csg@pyramid.UUCP (Carl S. Gutekunst) writes: > There was an alternative that never really caught on: ENQ/ACK handshake, where > it was the responsibility of the host to send an ENQ every 'n' characters, and > wait for the terminal to send an ACK. > > Of course, I'll bet that Gnumacs is already doing something special with ENQ > <CTRL-E> and ACK <CTRL-F>.... > Some terminals, TELETYPES probably starting this have ENQ labled as "WRU" (who are you) because when sent this sequence they send their "here is" or answerback sequence. VT100's support this as well, the message is set by doing "A" in the setup menu rather than snapping nubs off a drum and you can press ctrl-break instead of here-is. I always thought that setting the answer back to "HERE IS" was cute. -Ron