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: JBS%DEEP-THOUGHT@EDDIE.MIT.EDU (Jeff Siegal) Newsgroups: mod.computers.vax Subject: Re: Keyboards, ^S, ^Q, and ESC Message-ID: <12187585473.8.JBS@DEEP-THOUGHT.MIT.EDU> Date: Sun, 2-Mar-86 17:46:32 EST Article-I.D.: DEEP-THO.12187585473.8.JBS Posted: Sun Mar 2 17:46:32 1986 Date-Received: Tue, 4-Mar-86 04:03:48 EST References: <[MC.LCS.MIT.EDU].835884.860302.KFL> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 220 Approved: info-vax@sri-kl.arpa 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. Oh really? How about the ESC-ESC (or M-ESC) command you speak of? ESC is a real command in this usage. ESC is also a command in the sense that it tells Emacs to set the Meta bit for the next character. I repeat: If Emacs receives an ESC, should it set the Meta bit (on the next character)? Common usage says yes, but what if the ESC was only the lead-in to an ANSI sequence? 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? As I agreed before (perhaps not in a message sent to you), one should be able to send all 256 8-bit codes from the keyboard for obscure occasions like this. Applications should not depend on it any more than they depend on a 66 line screen; it is (should be) a luxury. 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. How, my I ask, do you go to beginning-of-paragraph? If ESC-[ acts like ESC, than M-A, M-B, M-C, M-D are up, down, right, and left, which is certainly not what they do in traditional Emacs. I have long since done this, so that VT100 arrow keys can move the cursor in Emacs. Then you have broken your 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? Exactly my point. ESC should not be a command (or a user-entered prefix). 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. VT100 has no excuse. VT200 uses 8-bit codes for other things. Meta is implemented in ASCII by toggling the 8th bit. But DEC precludes this by using the 8th bit for its multinational character set. ...and the 8-bit ANSI control codes. 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. They work just fine in EDT. I've never tried to use them with other DEC software. If the DEC software doesn't work, that's DEC's software developers' fault, not the fault of the codes used to represent the characters. 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. I fail to see how this follows from 8-bit codes. It may follow from broken DEC software. 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. (1 more time) The characters should be both there and usable. As it is, they can be output by applications (and by the VT200 setup mode) to make things easier to read by non-english speaking users. 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. The VT220 does not. The VT100 does, but only if equiped with the AVO. This is, of course, broken. 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. What you describe will only work in a half-duplex environment. With data flowing in both directions, this becomes unreasonable. Example: what do you do when the "send-next-page" commands come in too fast (on a split speed line, for example). 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. Was it really direct (i.e. terminal-->modem-->phone-line-->modem-->VAX 3000 miles away) or was there something in between to introduce buffering delays? ^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. Not really. This may be the function of your terminal. Most good implementations of XON/XOFF will repeat the XOFF several times if the output does not stop (i.e. XOFF at buffer-half-full, XOFF at buffer-3/4-full, XOFF at buffer-nearly-full), and will send XONs after a certain amount of time if output does not resume. The vt100's and vt200's implement the multiple XOFF, but not the multiple XON. The time I had to turn it off [smooth scroll] 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. 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. I maintain that it should be on if the user wants it on, and off if the user wants it off. It should neither be always on, nor always off. 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. On the vt100, if one uses smooth scroll without flow control, lost data results; it (smooth scroll) is NOT perfectly compatible with using ^S and ^Q as commands. Again, I never said that I liked vtXXX terminals; only that there XON/XOFF is too widely used to be ignored. I can hardly see why you wouldn't buy vt220's baased on this; you said you never used smooth scroll (and that it was off on all your terminals). [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). But the point is you shouldn't want to use ^S for search because it won't work well universally. 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. Ah, but if Emacs didn't make assumptions about what form of flow control would be used (if any), than there would be a (universally accepted command) other than ^S, ^Q, ESC, NUL, etc. for searching which could be used on ANY system, even if XON/XOFF was implememted in hardware (and could not be turned off). 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. Which means TPU is probably not for people who want to use Emacs. If they want to use Emacs, let them use Emacs. 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. I agree that the commands should be universal. However, consider how inconsistant using C-S, C-Q, etc. for commands in an environment which uses them for flow control. The biggest win in human interfaces is consistency. Take a look at the Mac. Well written software on the Mac needs very little documentation. The user interface is the same as other software. Take a user (on VMS, for example) who is used to the conventions used by all of the other utilities (e.g. TYPE, DIRECTORY, SORT, ACCOUNTING) utilities. If he wants to stop the output, he presses ^S, or the HOLD-SCREEN (or no-scroll) key. When he wants it to resume, he either presses ^Q or the HOLD-SCREEN key again. Put him in Emacs, and other software which ignores consistency, and watch him lose. My gripe is with software (like Emacs) which when put into an environment which makes assumptions (very common ones) about flow control, forces an inconsistant user-interface. ...Keith Jeff -------