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!linus!decvax!ittatc!dcdwest!sdcsvax!ucbvax!info-vax From: KFL@MC.LCS.MIT.EDU ("Keith F. Lynch") Newsgroups: mod.computers.vax Subject: Re: Keyboards, ^S, ^Q, and ESC Message-ID: <[MC.LCS.MIT.EDU].835884.860302.KFL> Date: Sun, 2-Mar-86 16:41:30 EST Article-I.D.: <[MC.LCS.MIT.EDU].835884.860302.KFL> Posted: Sun Mar 2 16:41:30 1986 Date-Received: Tue, 4-Mar-86 04:02:14 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 134 Approved: info-vax@sri-kl.arpa From: Jeff Siegal Giving the single code (27 - ESC) a meaning of its own prevents these other functions from being used. If you are familiar with Emacs, as you say you are, you should know that ESC is not a command, but is a command prefix, just like in the ANSI escape sequence set. My point here was that it is often necessary to key in one of these ANSI escape sequences, to give the terminal a command. If there is no ESC key on the terminal, how can this be done? An aside: I complained a while ago to RMS about GNUemacs not having support for ANSI sequences (on the input side) ... I am not sure what you mean. I'm not certain of ITS Emacs, but I know that with the Emacs we have on our VAX, it is easy to make ESC-[ act like ESC. I have long since done this, so that VT100 arrow keys can move the cursor in Emacs. ... 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), ... Not always. What about the meta-ESC command? How do you do that with just a meta key. (It is easy with just an ESC key, it becomes ESC-ESC). Most terminals don't have a meta key. The VT100 and VT200 don't. Meta is implemented in ASCII by toggling the 8th bit. But DEC precludes this by using the 8th bit for its multinational character set. This set is another halfway DEC idea. The problem with it (other than it eliminates use of the 8th bit for meta) is that the foreign alphabetic characters it implements are not treated like letters by any DEC software. Foriegners do not regard those as funny characters, but as regular letters. And it can cause no end of confusion when they are not treated as letters in DEC word processing programs, editors, compilers, assemblers, spreadsheets, database programs, or any other DEC or third party software I am aware of. This just means that foriegners have to carefully concentrate on each letter to try to decide whether it is in the English alphabet or not. It would be a lot easier on them if these unusable letters were simply unavailable, then they wouldn't waste time trying to use them. 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? Good point. But I was pointing out that the VT100 and VT200 need to send ^S a lot more often than that, and just for reception of plain text. That isn't reasonable. As for graphics, etc, once more the terminal should send something to request the next page (or however much) of data, rather than telling the host to stop when the terminal buffer gets too full. The latter is much more likely to lead to lost and garbled data. The trend is definitely away from ^S and ^Q and towards what I describe. All the modern graphics standards implement it. You cannot rely on the existance of out-of-band signalling. When I was logged into the VAX 3000 miles away, I was not going through any network, but was dialing direct. ^S ^Q was the only protocol DEC made available for such a phone call, and it failed horribly. Also, ^S ^Q is very sensitive to line noise, and to flakey connections. And what if your terminal or local host crashes? With my protocol, no data will be sent until it comes up again. With your protocol, since it isn't sending any ^Ss, data will continue to flow in an unbroken stream, to be lost into the ether. (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) The time I had to turn it off on the 3000 mile call was when we were just starting to learn how bad it was. It wasn't until a few months later that we decided it should always be off on all terminals. If someone prefers smooth scroll, why should they be prevented from using it by the lack of flow control? I still think smooth scroll is a bad idea, for many reasons (not the least of which is that long use of it has been known to cause users dizziness, nausea, and a strong feeling that the text is standing still and the building is sinking) but it is perfectly compatible with rational protocols. 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. And it also disables smooth scroll, even though smooth scroll is perfectly compatible with use of ^S and ^Q as commands, as can be seen on the VT100. One of many VT200 misfeatures. One of many reasons we decided not to buy any. ... the vt200 keyboard is based on an international standard. I wish they would stop with the international standards already. The only way they could have made the keyboard harder to use would be to place some of the keys on the bottom. [In Emacs] Any arbitrary sequence of characters should be able to set the meta flag for the next character. I agree. I also think that any character or sequence of characters should be able to be bound to any command. This has been the case for years. This is NOT possible for DEC's new TPU editor which will not allow you to use ^S for search (or for anything else). I think it a major win that when a friend of mine from Stanford visited recently, that even though he had no experience with VMS, once I put him into Emacs, he was completely at home. He was able to use the Emacs commands, including ^S for searching, and various ESC commands, despite the fact that to VMS these characters have very different meanings. If I had put him into TPU, even one that I had made as much like Emacs as possible, as soon as he had tried to search for something with ^S, the screen would have frozen, and if he did not realize this, no amount of trying anything (unless he happened to hit ^Q) would have helped him. I think it is a major win that an applications program can work the same way on many different operating systems. That in any Emacs anywhere, ^S will search. That in any Emacs anywhere, ^G will get me out of a funny state. But if Emacs was to be rebuilt to your specifications, on any VMS system ^S would freeze the screen and ^G would NOT get you out of that mode. I think that would be a major lose. ...Keith