[EMAIL PROTECTED] writes: > Hi all, > I whined before about mutt losing Up and Dn keys seemingly at > random. Well, it looks like it's not random after all: keymap gets > screwed after I telnet/ssh to other boxen on the network. Just now > it happened after I telnetted to an irix machine and that killed the > session with ^] - quit. > > Any idea what's happening there? -- I'd like to get this fixed, it's > very annoying when arrow keys stop working all of a sudden.
Ok, here's my guess: Your cursor keys are getting stuck in "Cursor Mode" when they should be in "Application Mode" or vice versa. Briefly, vt100-like terminals (such as xterm or the linux console, or that old vt220 rotting in my parents' spare room) have two modes that cursor keys can be in - one in which the keys transmit <escape>[A, <escape>[B, <escape>[C and <escape>[D, and one in which they transmit O (that's a capital "o") as the second character instead of [. (The reason for this has something to do with DEC marketing and the transition between the vt52 and vt100, I think) Anyway, terminals can be switched between the two modes simply by getting the appropriate escape codes from the other end. In an ideal world, there'd be only one set of codes transmitted by the cursor keys. In an almost ideal world, mutt would switch to "Application" mode on startup, switch back to "Cursor" mode if you spawned a shell or put it into the background, and then back again to "Apllication" mode once it either comes back to the foreground or the subprocess exits. (Or mutt would expect Cursor mode and switch there) Now, one of these things is not happening, and from your earlier posts my guess is that mutt expects the cursor keys to be in "Cursor" mode and just assumes that they'll be that way. I make this guess because each vc initially starts in "Cursor" mode and switches to "Application" mode only when told. ... <investigations of mutt, slang and jed I won't bother you with [1]>... Ok, here's what I think the end result is: 1. "Cursor" mode is the "normal" mode; if an application switches the keys to "Application" mode, it damn well better switch back. 2. jed can deal with both the "Cursor" and "Application" mode key sequences no matter what terminal it's on. I suspect that jed falls back on its own keybindings and isn't dependent on what slang tells it. 3. the Linux terminal responds to the vt100 codes that switch cursor state. These codes are NOT documented in the console_codes manpage. (though the related codes to switch the numeric keypad between numbers and escape sequences are documented) 4. For vt100 (and relatives), the terminfo entry says that the key sequence for "up" is Escape-O-A. The terminfo entry for the linux console says that the key sequence for "up" is Escape-[-A So I'm undecided as to who's to blame here. If all access to the console was done through the terminfo entries that Debian has, then all would be fine - no program would ever send the linux console the control codes to switch into Application mode, and every application would expect the console to be in Cursor mode. However, that's not what's happening here - something keeps switching your arrow keys into Application mode - probably this is some program on the far end that either has a terminfo entry for linux that says to do this or is using a vt100 definition for your terminal. I'll note that the terminfo entry for vt100 says that applications which expect to read in movement keys should, on startup, send the codes that switch the arrow keys to Application mode and cause the numeric keypad to send escape sequences. At the end of the application, that same terminfo entry says that they should send the codes that return the keypad to just numbers and the arrow keys to Cursor mode. As a temporary measure, if you've just disconnected and think that your cursor keys may be messed up, you can do TERM=vt100 tput rmkx Your keys should then work the next time you start up mutt. But what you probably want is a permanent fix. The most elegant solution I can come up with to fix this is to do the following as root: infocmp linux > /tmp/linux.tic echo ' smkx=\E[?1l, rmkx=\E?1l,' >> /tmp/linux.tic tic /tmp/linux.tic rm /tmp/linux.tic This will ensure that any application which wishes to use cursor keys in linux at least has a chance of sending the codes to switch the console into Cursor mode in case something switched it out. (Yes, I do mean for both smkx and rmkx strings to be identical) You can also run the same sequence of commands as a non-root user, but that won't change the system-wide setting. If you want, before you get rid of /tmp/linux.tic, you can send it to that IRIX system and use tic there to teach it about the linux terminal. Perhaps this adjustment to the terminfo entries for linux could be sent upstream; I guess filing a bug against ncurses is the way to do that.[2] By the way, I found the page http://www.mpimf-heidelberg.mpg.de/~rohm/computing/mpimf/notes/terminal.html to be a great little page that explained all manner of cursor-key mode issues. [1] This investigation was complicated by the fact that slang includes a seriously ugly hack specifically for vt100-like terminals that switches to Cursor mode if the application calls an obscure (undocumented) function. However, this function only sends these codes on vt* terminals, not linux. (When I first saw that Jed called this function while mutt did not, I thought I had found the answer; alas, however, this function does nothing when not on vt* terminals) [2] Someone else please do this; I've spent enough time on this already.
