Re: More on mutt losing its keymap
dmaziuk@yola.bmrb.wisc.edu 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.
Reply to: