On 2012-04-19 at 20:22:30 [+0200], Donn Cave <donn@xxxxxxxxxxx> wrote: > Adrien Destugues wrote: > > arfonzo is currently trying to improve Terminal compatibility with various > > BBS. He noticed that the escape sequences for arrows are now ESC + O + > > ABCD instead of the usual ANSI ESC + [ + ABCD. > ... > > Is there any problem reverting to the ANSI escape code for moving cursor ? > > Note that we could be talking about two different things here, because > a cursor and a cursor key are two very different things: > 1. the escape sequence sent to the TTY device when you press a cursor key > 2. the escape sequence that causes the cursor to move when received > from the TTY. That is correct, though a bit confusing, since it is observed from the terminal's point of view (and the order of the points doesn't match the order in the introducing sentence). From a command line application point of view: 1. When a cursor key is pressed, the application receives an escape sequence (more correctly: control sequence) from the terminal. 2. When the application wants to move the cursor in the terminal, it has to send a certain control sequence to the terminal. > For the cursor keys, both <esc>[A and <esc>OA etc. are correct, depending > on the current mode. Past that, I am a little fuzzy - by some accounts, > this is the `application keypad mode' setting that also turns the numeric > keypad into function & arrow keys. I am not sure that's right (though may > be widely implemented anyway), and there may be another mode involved. Just checked the VT100 and VT420 manuals and you are correct. The two modes are "ANSI Mode and Cursor Key Mode Reset" vs. "... Cursor Key Mode Set" (the naming differs in the VT420 manual). There's also VT52 Mode ("ESC A"), though that probably isn't relevant anymore. > Cursor movement is <esc>[A etc. Indeed. Anyway, how things (should) work in practice is that command line applications don't hardcode either kind of sequence. They should use the TERM environment variable to identify the terminal and interpret/use sequences matching the ones for that respective terminal. There are several mechanism which help with that. The oldest (?) and still used one is termcap (cf. /etc/termcap). There's terminfo which AFAIK is used (compiled into?) ncurses. There's the inputrc, which is used by the readline library -- which also uses termcap -- to map sequences sent by the terminal to commands. Interestingly for terminal type "ansi" termcap defines "ku=\E[A" (meaning "cursor key up" is "ESC [ A"), but for terminal type "xterm" it is "ku=\EOA" ("ESC O A"). So strictly speaking a terminal that identifies itself as "xterm" (like Haiku's Terminal) should send "ESC O A" or applications that use termcap only won't interpret the cursor key up sequence correctly. However, in openSuse 11.4 /etc/inputrc maps both sequences to "previous-history", so applications using readline work fine in either case. To sum this up, even though it breaks termcap-only appplications (which may not exist in practice anymore), changing the cursor key sequences to match the Unix xterm-like terminals (particularly the xterm application) probably does make sense, but inputrc needs to be adjusted. What I wrote in my previous mail was a bit ambiguous: termcap must not be adjusted in the same sense. It can be updated to a new version (should there be one), though I doubt that this changes anything in this respect. The same holds true for ncurses I guess. CU, Ingo