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