Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: utzoo!decvax!decwrl!ucbvax!info-vax From: JBS%DEEP-THOUGHT@EDDIE.MIT.EDU (Jeff Siegal) Newsgroups: mod.computers.vax Subject: Re: Keyboards, ^S, ^Q, and ESC Message-ID: <12187370727.27.JBS@DEEP-THOUGHT.MIT.EDU> Date: Sat, 1-Mar-86 22:06:54 EST Article-I.D.: DEEP-THO.12187370727.27.JBS Posted: Sat Mar 1 22:06:54 1986 Date-Received: Mon, 3-Mar-86 02:02:22 EST References: <[MC.LCS.MIT.EDU].835164.860301.KFL> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 201 Approved: info-vax@sri-kl.arpa 1) The ESC key is dead. It is an unmanagable concept. If you don't know why, I'll be glad to explain it. Please do. [lots of flamage about VisiCalc, etc. All keyboards have ESC keys (paraphrased)] Especially on ANSI terminals, as they use ESC sequences for virtually everything. Exactly the point. My concept of unmanageable comes from the fact the the ESC code is used as the lead-in for ANSI character sequences (most common ones start with ESC-[, which has an 8-bit equiv. I can't remember; some others start with ESC-O, still others with ESC-P). These codes are used by the terminal to report the use pressing the function or other special keys, to report the cursor position, to report mouse position, and mouse button activation, etc. Giving the single code (27 - ESC) a meaning of its own prevents these other functions from being used. An aside: I complained a while ago to RMS about GNUemacs not having support for ANSI sequences (on the input side) and even offered to write the code and make the appropriate mods to the keyboard interface code. His response was that he did not want to eliminate the traditional Emacs command ESC-[, since he used that and did not use ANSI terminals. I tried to explain that ESC was just a kludge for the lack of a Meta key, and that Meta would be implemented by another prefix key on ANSI terminals (Gold key on a VT100, perhaps), but I was ignored (how dare you speak out against the ESC key and other religious nonsense). 2) C-S, C-Q are too commonly used in the communcations protocol to be useful in applications. I hurts me to say this, since I'm generally an EMACS fan too. ^S ^Q flow control is an idea whose time has passed. With international networks, the line delays are too long. When I used a VT100 terminal to log onto a VMS VAX 3000 miles away, I had to turn smooth scroll off, as the delay on the line was causing the terminal buffer to overflow before the host got the ^S, resulting in garbage on the screen. Non-broken applications of XON/XOFF use it only for flow control over a single comm line (e.g. EIA RS-212). For example, between the terminal and the computer (or terminal concentrator) or between the computer and a printer on an async. line. There is no out-of-band data path for communications over an EIA line with 4 conductor wire. If people are willing to use 6 conductor cable, there is hardware flow control, but in most cases this is not done, and all hardware does not support it. It will also not work over a modem. As you say, using XON/XOFF over a network is likely to fail horribly. Over network lines, the network protocol should (and does) provide out-of-band flow control. In any case, the use over any part of the link between the user and the computer of the C-S and C-Q chars prevent their use by applications programs. The only reason for ^S ^Q flow control is because the terminal can't keep up with the data coming in. At speeds less than 19,200 baud, I don't think there is any excuse for that. How about a graphics command sequence to rotate a figure x degress in three dimensions (or even to fill a large region on the screen)? How about terminals with optional hard-copy of the recieved characters? How about a terminal in SET-UP mode? How about a LONG sequnce of configuration codes? My H19 terminal, costing less than half the cost of a VT100 at the time I got it, can keep up with any and all data and ESC sequences even at 9600 baud. There is not reason why DEC terminals should not be able to. See above. One reason for a terminal being unable to keep up is smooth scroll. Smooth scroll was never a terribly good idea. We encourage our VMS users not to use it since processing all the ^Ss and ^Qs eats up a significant percentage of our VAX-11/785. Nonsense. If you are going to make such outrageous claims, please provide either a reference or a way for someone else to demonstrate it. (BTW: Do you use smooth scroll or not; above you said that you had to "turn off smooth scroll", implying that it was normally on) And because sending a broadcast message to a user who is ^Sd can cause the broadcasting process to freeze. Yes, this is a VMS bug. I think that smooth scroll was intended to make text easier to read as it scrolls. Text can be difficult to read if it scrolls at a variable rate. However, this problem was solved years ago. The solution is for the host to send one screen of information at a time and to wait for the user or the terminal to request another screen. The new text then overwrites the old text from the top, and nothing ever scrolls. Note that no amount of network delay can result in any data being lost or garbled, since nothing is sent until the terminal says it is ready for another screenful. This is strictly your preference. I perfer jump scroll to both smooth scroll and non scrolling. If someone prefers smooth scroll, why should they be prevented from using it by the lack of flow control? [flame about vt100 no-scroll key] ^S ^Q flow control is not incompatible with other uses for ^S and ^Q. Many terminals, including the VT100, will use ^S and ^Q for flow control and will allow the user to type those characters for use with applications programs, such as Emacs, that use them. This is only the case if auto-flow-control is turned off. If it is on, the C-S and C-Q keys change the internal "screen-frozen" state bit. The terminal only sends XON/XOFF's when the internal buffer reaches certain documented states (i.e. number of characters in buffer, etc.) The VT200}, however, simply ignores ^S and ^Q when typed by the user. This is not reasonable behavior. The VT220 behavior is the same as the VT100. Turn XON/XOFF off on the "comm" setup menu, and C-S and C-Q will generate the control chars, but the terminal will not use those codes for flow control. Neither is it reasonable that, while the VT200 has dozens of keys that send ESC followed by several characters, it has no key that simply sends an ESC. This is exactly the point. If the terminal sends an escape, the application has no way to know if there are more characters following. Assuming that an ESC is a command by itself prevents the other features from being used. Fortunately, it is easy to have Emacs Depends on your version of Emacs. interpret the backquote key (which is where the ESC key belongs) This may be your position, and others may share it (I may share it), but the vt200 keyboard is based on an international standard. as an ESC, at the expense of having a hard time sending a real backquote character. But this is no solution, since most programs that require an ESC as input do not allow users to rebind keys in this way. I will make one small concession in my position; new terminals probably should have an ESC key so as to not break existing software (a temporary violation of the standard) but... Neither should terminals or computers be set up such that users have to fight against them, and have to do obscure and complicated rebindings, to be able to use features that most users have now been taking advantage of for years. applications should be running (not walking) away from the use of ESC as a command on its own. In particular, it is not reasonable for a terminal to not let the user send all 128 ASCII codes, or to not be able to do so without some sort of rebinding or reprogramming of the terminal. The trend, in fact, is away from keyboards with missing codes, such as the Apple II, What the hell did the Apple ][ keyboard have to do with proper designs of keyboards/terminals? The international extension of ASCII (ISCII :-)), uses all eight bits. and towards keyboards that allow users to send all 256 possible 8 bit codes. OK. There are the missing 128 characters. DEC is not causing the problem. The problem is applications which have not evolved to co-exist with modern terminal/communications standards. It looks to me like DEC *IS* causing the problem. No other modern computers or terminals that I am aware of have these misfeatures. Please tell me how Emacs should 'evolve' to compensate for this lossage. Partly explained above. Any arbitrary sequence of characters should be able to set the meta flag for the next character. If TPU is an 'evolved' Emacs, I will choose the old way any day of the week. Not being experienced in TPU, I'll just say that your logic is defective (if Emacs is old, and TPU is new, and TPU is worse than Emacs, than anything new must be worse than the old way) ...Keith Jeff -------