Bug#2313: xterm keymapping problems suspected
(Apologies for discussing us.map as if it were the only keymap
table. I presume the points made in relation to us.map are generally
true for other keymap tables as well, but have not checked)
kaszeta@me.umn.edu said:
> >Also, with "stty raw; cat -v", I see that the Backspace and DEL
> >keys both produce ^? ('\177') in an xterm. (the "cat -v" will
> >need to be killed from another terminal session after this, and
> >"reset" or "stty sane" done). The Backspace and DEL keys should
> >produce distinct sequences.
>
> Is this a bug or a misfeature...? Xfree inherits many of the
> keymappings from the spawning tty, and on most linux distributions
> (including debian) the default keymappings for the text console (US
> keyboard maps at least) map both these keys to the same value...
I don't know where xterm gets its keymappings, but I note that
`infocmp linux` and `infocmp xterm` produce quite different output.
The keymappings reported by `infocmp linux` seem to track the keymap
table definitions in us.map, and the keymappings reported by
`infocmp xterm` do not.
> For example, /usr/lib/kdb/keytables/us.map on default 0.93R6 systems
> maps both keycodes 9 and 111 to the same code (mostly, one is mapped
> to Delete and one to Remove, not really sure the difference but by the
> time X gets done they are the same).
I think you meant to say 14 amnd 111, not 9 and 111. key 14 is the
backspace key and key 111 is the utility keypad DEL key (key
83 is the keypad period/DEL key, and is switched between period
and DEL according to key 69 (NUMLOCK) keypresses by some mechanism
I haven't tried to identify). key 9 is the '8' key in the numeric
row above the alpha keyboard. At least that's true on the system
I have handy at the moment.
Anyhow, us.map provided by kbd-0.90-3 maps keycode 14 to Delete and
111 to Remove. Remove is defined in that file as "\033[3~". Delete
isn't defined. I'm not sure how, or if, the Remove in us.map relates
to the Remove reported by dumpkeys(1).
In another version of the us.map file, I noted that keycode 14
was mapped to Delete and shift keycode 14 was mapped to BackSpace.
That isn't true in my current us.map, and I'm not sure when the
change was made. us.map from kbd-0.90-3 doesn't seem to map any key
or key combination to Backspace.
I reported this bug as a consequence of testing the ae(1) text editor
in an xterm. It's common for text editors to want to delete the char
to the left of the cursor when the BackSpace key is pressed, and to
delete the character under the cursor when the DEL key is pressed.
These keys need produce distinct sequences so that they can be
distinguished from one another. I see that the kbd-0.90-3 us.map
mappings for these keys is distinct, and that the keys produce the
distinct sequences specified in us.map for a linux VC, but that they
do not produce distinct sequences in an xterm.
When I looked at us.map, I was expecting to find keycode 14 mapped
to BackSpace and keycode 111 mapped to Delete. I guess that there
must be some logical reason why keycode 14 is mapped to Delete and
keycode 111 to "\033[3~", but it's not obvious to me.
> Shouldn't this be fixed? Would also cut down on the 'Backspace
> doesn't work in Netscape' complaints... :)
Reply to: