charles@hp-pcd.UUCP (charles) (08/19/85)
My apologies for asking about something that was recently posted here, but I didn't need the info until it was removed from all of our machines. What was the consensus about the characters to replace ^S and ^Q when these are used for flow control? I will be setting the standard for a large number of local users and I would rather not set Yet Another Standard. Direct email would be appreciated. Thank you. Charles Brown hplabs!hp-pcd!charles
charles@hp-pcd.UUCP (charles) (08/23/85)
Profound silence... Perhaps the mail to this site is down. Please post the replacements for ^S and ^Q here. Thank You Charles Brown hplabs!hp-pcd!charles
jqj@cornell.UUCP (J Q Johnson) (08/30/85)
In article <7500002@hpcvcd.UUCP> charles@hp-pcd.UUCP (charles) writes: >What was the consensus about the characters to replace ^S and ^Q when >these are used for flow control? I don't think a clear consensus emerged, but the trend was towards substituting ^\ for ^Q and ^^ for ^S. This is the convention we are using at Cornell, and the convention I would like to see other sites adopt. It is, I think, the convention RMS describes in the gnu emacs installation instructions. The ^\ part is fairly clear. The problem with ^^ is that it's the escape character for kermit. So a possible alternative is to use BOTH ^^ and ^] as substitutes for ^S. Note that in gnu emacs the substitution should be done using code such as the following (from our site-init.el): ;; Turn on CBREAK and flow control (wish we didn't have to do this!) (set-input-mode nil t) ;; Make a translate table that does the identity translation. (setq keyboard-translate-table (make-string 128 0)) (let ((i 0)) (while (< i 128) (aset keyboard-translate-table i i) (setq i (1+ i)))) ;; Now alter translations of some characters. (aset keyboard-translate-table ?\^\\ ?\^q) (aset keyboard-translate-table ?\^^ ?\^s)
warren@ihnss.UUCP (Warren Montgomery) (09/03/85)
Watch out for ^^. It is a nasty one to type on most terminals, but worse yet, there are more than a few terminals that can't generate it at all. I have yet to see a "good" solution to the loss of ^S/^Q in emacs, only lots of imperfect ones. -- Warren Montgomery ihnss!warren IH ((312)-979) x2494
charles@hp-pcd.UUCP (charles) (09/09/85)
>Watch out for ^^. It is a nasty one to type on most terminals > Warren Montgomery Alas! On half of the terminals around here it takes three fingers to type ^^. For search-forward that is not reasonable. Furthermore, we have historically used ^\ for expand-mlisp-variable. I am setting up the local defaults as: expand-mlisp-variable ^\ quote-character ^^ search-forward ^] Altho there is some sense to using ^\ for quote, I think expand-mlisp-variable is used more. Besides, if you squint your eyes just right the ^^ looks like a quote :-). Thanks for the responses Charles Brown hplabs!hp-pcd!charles
rms@prep (11/02/85)
From: Richard M. Stallman <rms@prep> As far as I can understand it, the "xo" flag says that a terminal USUALLY uses flow control, and recommends generating no padding. This does not imply that the terminal cannot be operated without flow control. In fact, it is possible that, if given padding as specified by the termcap entry, the terminal might just never generate XOFF. Since avoiding the use of flow control is always best, it would be undesirable for Emacs to assume that flow control must be used on these terminals. I recommend that Emacs users do everything they can to avoid the use of nontransparent flow control protocols, including using padding, turning off flow control in the terminal, selling the badly designed terminals, or throwing them off the roof.
jqj@cornell.UUCP (J Q Johnson) (11/08/85)
We've beaten this topic to death, and it doesn't belong on net.emacs anyway. Let's at least move the discussion to net.dcom or something! To summarize: 1/ many people don't like XON/XOFF flow control. In particular, most versions of Emacs, since they traditionally use C-s and C-q as important commands, work MUCH better in a non-flowcontrolled environment. 2/ it is possible in most cases to substitute padding for XON/XOFF. However, padding calculations can be VERY complex. One generally doesn't want to pad for the worst case; on a VT100 at 19.2Kb, this would be a pad after every single character! Also, padding is a problem with terminal emulators, since my emulated VT100 (a VT101 is one such emulator) may have very different padding requirements from a real one. 3/ doing padding requires that the program know a great deal about the terminal and about display processing. At the very least it needs to know the output baud rate (which is not always available over network connections), and the precise terminal type. Now that it is becomming common to put a windowing system between the program and a "virtual" terminal, it becomes necessary either for the program to know about the characteristics of that windowing system or for the windowing system to be sufficiently fast to handle any incoming data rate. 4/ padding uses up bandwidth, which can sometimes be too costly (e.g. if you are paying Tymnet a percharacter charge). Using timed delays, however, does not work since downstream buffering can completely foul up your timing. 5/ in some environments flowcontrol cannot be disabled. For example, some "intelligent" front ends insist on processing ^S/^Q. In such situations, your ONLY option is to use a flow-controlled version of Emacs. Current GNU Emacs has such an option, as do some versions of Gosling Emacs.