waters@ORACLE.DEC (Greg Waters, 225-4986, HLO2-1/J12) (03/11/86)
> ESC is used in the Unix ... screen editor 'vi' ... > Yet, vi is quite capable of understanding special-key sequences beginning > with ESC, even though hitting ESC in command mode by itself just sounds the > bell.... vi waits for a short period after getting an ESC to see what else > it gets right afterward. If the ESC was immediately followed by the rest of > a special-key sequence, vi obeys it. > >| dan levy | yvel nad | Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, >| at&t computer systems division | vax135}!ttrdc!levy Obviously, this only works if the terminal is connected directly to the computer. Put a stat mux in the way, and all bets are off. Note that this vi does something harmless with what it THINKS is a lone escape. So, the problem isn't solved at all -- a lone <ESC> still can't be reliably used as a meaningful command. What does this vi do when <ESC> arrives, the timer expires, and then the rest of a valid escape sequence comes in? Interpret the sequence without the escape, or beep AND interpret the ANSI sequence? And now my question. The life of lone escapes can indeed be extended using timer hacks. All senders of information would have to encode lone escapes as <ESC> <a-time-gap>, and all direct receivers would have to implement a timer as this vi has. (This protocol comes for free when the system is a terminal connected by hard line to a computer. Well, until you turn on flow control, anyway.) Every non-real-time part of the system has to have an ANSI switch, which enables these timers and the special <ESC> treatment. Obviously, this business of using lone escapes in an ANSI environment is a KLUDGE, but it does offer the possibility of reasonable support for existing software (such as normal EMACS with hardware flow control). I know that many of my company's current products do implement special treatment for ANSI sequences, whenever there's a way to communicate the switch setting through the parts of the system. What about the rest of the market? Whose stat. muxes, TIPs, terminal networks, etc. try to keep lone escapes straight? Thanks in advance for the info, which should be posted to net.dcom (or a suitable ARPAnet list) ONLY. (N.B. My stand on this issue is compatible with my employer's. However, this posting DOES NOT and was not meant to express an opinion on the issue, whether mine or that of DEC.) Greg Waters -- DEC Hudson, MA UUCP: {...|decvax|...}!decwrl!dec-rhea!dec-oracle!waters ARPA: waters%oracle.DEC@DECWRL.ARPA
KFL@MC.LCS.MIT.EDU ("Keith F. Lynch") (03/15/86)
Actually, recognition of lone escapes is not necessary for Emacs to work right. It is always unambiguous when a command ends. If ESC-A is a command then there is no ESC-A-B command. Of course this means you can run into difficulties when binding commands to keys which producs escape sequences. On an ANSI terminal, most such keys produce ESC-[-something. So ESC-[ cannot be a command itself. On non-ANSI terminals the arrow keys might generate ESC-A ESC-B ESC-C and ESC-D. So these commands cannot be used to mean things other than what the arrow keys mean. This is unfortunate since these are well known Emacs commands. The solution Gosling's Emacs uses is to allow case-sensitive commands. The up-arrow key might produce ESC-A, and to go to the beginning of the sentence you have to enter ESC-a (lowercase A). The only problem with this is that some people like to edit whith CAPS-LOCK on, and this makes it difficult. Another solution is to use timing hacks. It has been pointed out that this doesn't work through MUXes and networks as they only guarantee that characters will be received in the right order (and sometimes not even that!) but guarantee nothing about timing. But this is an excellent solution on microcomputers and other single user machines. Thus ESC-A would mean one thing while ESC (pause) A means another. Of course these principles do not apply only to Emacs. This is important for any utility which uses arrow keys and/or function keys and which also allows ESC commands. ...Keith