Bug#2313: xterm keymapping problems suspected
Stephen Early <sde1000@cam.ac.uk> said:
> I'm sorry it's taken me so long to get around to joining in this thread.
> I can see this one going on a long time...
Yeah. Looks messy. keymaps, terminfo, xterm, ...; lots of stuff
from widely separated parts of the distribution bear on this.
> [...]
> On a vt, Home produces ESC [ 1 ~
> In an xterm, Home produces ESC [ nul
>
> I agree this is dodgy. I'll look into changing it; [...]
This looks to me like it needs to be fixed as well.
> [...]
> xmodmap -e "keycode 22 = BackSpace"
> [...]
> I'm open to suggestions about what the Debian X packages should do here.
> My personal feeling is that giving the backspace key the BackSpace keysym
> and the delete keys the Delete keysym is the right way to go. I'm not too
> sure how to accomplish this; in particular I don't want to have any
> hard-coded keycodes in the packages, even in the sample config files. It
> may work for all of us, with our US or UK standard keyboards, but people
> using other keyboards could have problems.
>
> I also want to know how people feel about backspace producing ^H in an
> xterm by default; this will be 'new' behaviour for most Linux users I think.
This goes beyond the X packages, I think.
in MSDOS (I booted it to check), BS on the command line deletes one char
left. DEL, if at the end of the command line, does nothing.
Under SunOS and other unix systems I recall using, it's normal for
users to either have "stty erase ^H" or "stty erase ^?" done in a
startup file. After doing this, it's normal for either the BS or DEL
key, but not both, to delete one char left. A manual ^H keypress
(predictibly) usually acts like a BS keypress.
Under debian linux in a VC, BS and ^H both delete one char left
regardless of which of "stty erase ^h" or "stty erase ^?" is done.
The DEL key does not work as expected (I'd expect it to produce a DEL
char, not a "\033[3~" escape sequence).
It looks to me as if the /usr/lib/kbd/keytables/*.map files should have:
keycode 14 = Backspace Backspace
keycode 111 = Delete
And that "stty erase ^H" should be set up by default. Those changes
make the linux VC operate pretty much as I'd expect, and pretty much
as MSDOS users might expect Where it operates not as I expect is with
the keypad Period/DEL key. This is specified in the *.map files as
keycode 83 = KP_Period
However, with the NumLock key released, key 83 produces the Remove
string of "\033[3~", even with keycode 111 mapped to Delete instead
of Remove. I haven't checked where the translation takes place, but
I'd have hoped that this would instead translate to producing whatever
keycode 111 produces.
> > Also, "infocmp xterm" shows some missing key capability entries and
> > some entries which don't match what xterm produces for the
> > corresponding keys. That'll need to be brought into sync with what is
> > produced by an xterm. This is an ncurses issue, not an xterm issue, but
> > it can't be fully addressed until xterm behavior is finalized (hopefully
> > eliminating the problems discussed above).
>
> Here is the termcap file from the xterm source:
> [...]
Some of that (e.g. kf1 thru kf4, probably others) doesn't jibe with
what I see by testing or with what I expect. I don't have a recent
debian system with X11 installed handy just now, so can't cite
individual differences. Keymapping differences are easy to check for,
though.
> # vi may work better [...]
I don't think we should be specifically concerned with making vi
work well. In fact, I was testing with ae (not vi). whatever
the arbitrary application is, it has a right to expect better
keypress translations than are currently available (IMHO).
The xterm terminfo issue currently involves ncurses, since ncurses
provides the xterm terminfo file(s). Perhaps xbase should provide these
files, so as to reduce the need to coordinate this between two maintainers.
> Here is (a part of) the README from the xterm source:
>
> Abandon All Hope, Ye Who Enter Here
[...]
Yeah. I was looking at this last night. I quickly decided that
my time was better spent elsewhere ;-).
Reply to: