[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#2313: xterm keymapping problems suspected

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...

On Mon, 12 Feb 1996, Bill Mitchell wrote:

> I see with "cat -v" that the HOME key produces ^[[^@
> (escape, '[', '\000') from an xterm.  This seems improper.

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 will be done
either by modifying the source code (which is awful), or by providing a
default set of translations for the vt100 widget.

> 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.

There are (at least) two problems here. At least on my system, the
backspace key and the various delete keys all end up with the 'Delete'
keysym. It's possible to remap the backspace key to have a BackSpace
keysym using the following command, at least on UK and US keyboards:

xmodmap -e "keycode 22 = BackSpace"

This, as expected, makes xterm produce ^H whenever backspace is pressed.
I agree that this behaviour is more correct, but it can be annoying;
although readline treats ^H and ^? the same by default, the kernel tty
driver doesn't, and only allows one 'rubout' key. This can lead to things
like this:

myrddin:~$ cat

(I habitually press backspace instead of delete).

The behaviour is different under Solaris:

hammer:~$ cat

(I pressed exactly the same keys the second time; the backspace key just
made the cursor move one character to the left, without overwriting the
character there.)

FYI, the xterm code has special case handling for the various 'Delete'
keysyms, but just relies on the string returned by XLookupString() for
the BackSpace keysym.

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.

> 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:

# $XConsortium: termcap,v 1.12 94/04/12 15:01:29 gildea Exp $
vs|xterm|xterm-24|xterms|vs100|xterm terminal emulator (X Window System):\
v2|xterm-65|xterm with tall window 65x80 (X Window System):\
vb|xterm-bold|xterm with bold instead of underline (X Window System):\
# vi may work better with this entry, because vi
# doesn't use insert mode much
vi|xterm-ic|xterm-vi|xterm with insert character instead of insert mode:\

Here is the terminfo file from the xterm source:

# $XConsortium: terminfo,v 1.10 94/04/13 11:43:14 gildea Exp $
# meml locks memory above the cursor; memu unlocks (ala HP terminals)
xterm|xterm-24|xterms|vs100|xterm terminal emulator (X Window System),
	am, bel=^G,
	cols#80, lines#24,
	clear=\E[H\E[2J, cup=\E[%i%p1%d;%p2%dH,
	cud=\E[%p1%dB, cud1=\n, cuu=\E[%p1%dA, cuu1=\E[A,
	cub=\E[%p1%dD, cub1=\b,	cuf=\E[%p1%dC, cuf1=\E[C,
	el=\E[K, ed=\E[J,
	home=\E[H, ht=^I, ind=^J, cr=^M,
	smir=\E[4h, rmir=\E[4l, mir,
	smso=\E[7m, rmso=\E[m, smul=\E[4m, rmul=\E[m,
	bold=\E[1m, rev=\E[7m, blink@, sgr0=\E[m, msgr,
	enacs=\E)0, smacs=^N, rmacs=^O,
	smkx=\E[?1h\E=, rmkx=\E[?1l\E>,
	kf1=\EOP, kf2=\EOQ, kf3=\EOR, kf4=\EOS,
	kf5=\E[15~, kf6=\E[17~, kf7=\E[18~, kf8=\E[19~, kf9=\E[20~,
	kf11=\E[23~, kf12=\E[24~, kf13=\E[25~, kf14=\E[26~, kf15=\E[28~,
	kf16=\E[29~, kf17=\E[31~, kf18=\E[32~, kf19=\E[33~, kf20=\E[34~,
	kfnd=\E[1~, kich1=\E[2~, kdch1=\E[3~,
	kslt=\E[4~, kpp=\E[5~, knp=\E[6~,
	kbs=\b,	kcuu1=\EOA, kcud1=\EOB, kcuf1=\EOC, kcub1=\EOD,
	meml=\El, memu=\Em,
	smcup=\E7\E[?47h, rmcup=\E[2J\E[?47l\E8,
	sc=\E7, rc=\E8,
	il=\E[%p1%dL, dl=\E[%p1%dM, il1=\E[L, dl1=\E[M,
	dch=\E[%p1%dP, dch1=\E[P,
xterm-65|xterm with tall window 65x80 (X Window System),
xterm-bold|xterm with bold instead of underline (X Window System),
	smul=\E[1m, use=xterm,
# vi may work better with this entry, because vi
# doesn't use insert mode much
xterm-ic|xterm-vi|xterm with insert character instead of insert mode,
	smir@, rmir@, mir@, ich1=\E[@, ich=\E[%p1%d@, use=xterm,

Here is (a part of) the README from the xterm source:

                        Abandon All Hope, Ye Who Enter Here

This is undoubtedly the most ugly program in the distribution.  It was one
of the first "serious" programs ported, and still has a lot of historical
baggage. Ideally, there would be a general tty widget and then vt102 and
tek4014 subwidgets so that they could be used in other programs.  We are
trying to clean things up as we go, but there is still a lot of work to

Here is (a part of) the main.c file from the xterm source:

 *                               W A R N I N G
 * If you think you know what all of this code is doing, you are
 * probably very mistaken.  There be serious and nasty dragons here.
 * This client is *not* to be taken as an example of how to write X
 * Toolkit applications.  It is in need of a substantial rewrite,
 * ideally to create a generic tty widget with several different parsing
 * widgets so that you can plug 'em together any way you want.  Don't
 * hold your breath, though....

Steve Early

Reply to: