Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!sri-spam!ames!ucbcad!ucbvax!ICST-CMR.ARPA!rbj From: rbj@ICST-CMR.ARPA (Root Boy Jim) Newsgroups: comp.emacs Subject: Re: What's wrong with flow control? Message-ID: <8612011910.AA05601@icst-cmr.arpa.ARPA> Date: Mon, 1-Dec-86 14:10:41 EST Article-I.D.: icst-cmr.8612011910.AA05601 Posted: Mon Dec 1 14:10:41 1986 Date-Received: Mon, 1-Dec-86 21:28:21 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 97 > gore@nucsrl.UUCP writes: > >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... > That's what CTS & RTS (clear-to-send and request-to-send) are for: > hardware handshaking. And if UNIX tty drivers and related hardware > were set up to do it properly, that would be the way to go. YOU got it right, Karl, but just as many people would use DTR & DSR, or some other random signal. In any case, it only solves half the problem, as I will elaborate below. > Otherwise, the solutions are either to make a terminal for which > padding can be sufficiently easily specified, so that you basically > trust the terminal not to get behind and screw up; Padding is an ancient concept, one that no one should have to deal with. It's computationally intensive, confusing at best, and frequently wrong. > or just make a > terminal whose firmware is faster than its fastest data rate. (Don't > laugh, it's not that difficult. It's a poor commentary on DEC et al > that they can't do so themselves.) Or that they chose another method. It's easier to stick a kilobyte in a terminal and send ^Q/^S when certain limits are reached rather than worry about miniscule timing intervals. In short, it's dynamic and adaptive rather than static and rigid. Besides, it only solves *part* of the problem. If I need to stop a long output (e.g. `ls -l /etc), there is no `drop CTS' key. All I can do is type a character, or drop DTR (by turning of my terminal), not much of a solution. Padding doesn't solve that problem. Okay, so I could pipe it thru a pager (but I didn't when I started that monster grep and I changed my mind), or I could even put the pager in the tty handler (but that usurps another character or two and requires) modes to turn the feature on/off. > As it is, making ^S/^Q into flow-control chars forces them into being > an awful special case. If people aren't to type ^S or ^Q, why is ^U > acceptable? Or ^Z? Or ^C? Or any of those other characters people > have learned to love on their ASCII terminals? Well, strictly speaking, you can't. Perhaps you might look at the ANSI spec for ASCII (X3.64 or something). It describes several classes of control characters (in no particular order and with no particular accuracy, it's been awhile since I looked at it): [1] Format Effectors -- White space to UNIX types. These things don't print anything, but make printers and things go bump in the night. They consist of BS, HT, LF, VT, FF, and CR. Possibly BEL. [2] Communications -- Protocol stuff. SOH, STX, ETX, EOT, ACK, DLE, NAK, SYN, ETB, CAN, EM, SUB. [3] Character Set Extension -- ESC, SO, SI. Alternate character sets. [4] Data Formatting -- FS, RS, GS, US. Interestingly enuf, SPC can be thought of as WS, a `word separator'. [5] Device control -- DC[1-4]. Once upon a time turned ASR-33 paper tape readers/punches on/off. XON & XOFF in more modern times. [6] Whatever I missed. NUL and DEL are somewhat special, possibly they go in the communications category, but they often have media problems (magtape) or special significance (paper tape). In any case, controls characters are reserved *for the implementation* (all the system stuff) while the graphics are reserved *for the users*. The fact that you see *any* control characters at all is gravy. Some systems, like VMesS, filter them `for' you. > While I sometimes disagree with the (perhaps caustic) view taken by > Richard toward ^S/^Q, I have to agree with the basic position: it's a > bad design. At least, to his credit, he hacked in `set-input-mode'. There isn't much `protocol' to async ascii, but flow control seems to be universally required. Most people use the ^Q/^S convention. With unknown gateways, concentrators, and translation boxes between here and there, it gets weirder than just plain padding. M-x yours-truly RET > -- > Karl (Root Boy) Jim Cottrell I wish I was on a Cincinnati street corner holding a clean dog!