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: KFL@MC.LCS.MIT.EDU ("Keith F. Lynch") Newsgroups: mod.computers.vax Subject: Keyboards, ^S, ^Q, and ESC Message-ID: <[MC.LCS.MIT.EDU].835164.860301.KFL> Date: Sat, 1-Mar-86 18:17:19 EST Article-I.D.: <[MC.LCS.MIT.EDU].835164.860301.KFL> Posted: Sat Mar 1 18:17:19 1986 Date-Received: Mon, 3-Mar-86 02:01:02 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 91 Approved: info-vax@sri-kl.arpa From: Jeff Siegal 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. The escape key is necessary for lots of software, from Emacs to VisiCalc. On virtually every ASCII keyboard it is in a prominent place, and since ESC is very seldom a part of any text or numeric input to a program, it makes a very useful command key or command prefix key. I have used programs which use ESC under VMS, UNIX, TOPS-10, TOPS-20, CP/M, MS/DOS, Apple-DOS, and ITS. Most major programs that I write use the ESC key for something. The only ASCII keyboards I can recall ever seeing that don't have it are the VT200 and MicroVAX keyboards made by DEC. Even the stripped down Apple II keyboard has an ESC key. These days, with screen editors, spreadsheets, database programs, and other screen oriented software all the rage, the ESC key is more important than ever. Especially on ANSI terminals, as they use ESC sequences for virtually everything. 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. 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. 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. 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. And because sending a broadcast message to a user who is ^Sd can cause the broadcasting process to freeze. 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. I was dismayed to discover that DEC is apparently unaware of this. As demonstrated by the fact that the NO-SCROLL key on the VT100 does not switch the terminal from scroll mode to wrap mode as I had guessed the first time I saw it, but simply freezes the screen, preventing any new text from being displayed. ^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. The VT200, however, simply ignores ^S and ^Q when typed by the user. This is not reasonable behavior. 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. Fortunately, it is easy to have Emacs interpret the backquote key (which is where the ESC key belongs) 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. 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. 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, and towards keyboards that allow users to send all 256 possible 8 bit codes. 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. If TPU is an 'evolved' Emacs, I will choose the old way any day of the week. ...Keith