Red Hat Bugzilla – Bug 169347
"home" and "end" keys in xterm generate wrong escape sequences
Last modified: 2007-11-30 17:11:14 EST
Description of problem:
"home" and "end" keys in xterm generate wrong escape sequences - not matching
"home" generates "\E[1~" and "end" generates "\E[4~". According to terminfo
database proper sequences are:
$ infocmp -1 xterm | egrep khome\|kend
This causes that home/end keys do not work in several console programs in xterm:
for example "mutt", "less", "info", "pinfo". They work in other terminal
emulators, like gnome-terminal or kterm, which generate proper sequences.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. start "xterm"
2. type "cat" [enter]
3. press [home]
4. press [end]
The sequences generated by xterm are proper for linux console:
$infocmp -1 linux | egrep khome\|kend
Several programs do have workarounds for bad escape sequences, so home/end keys
do work in them - everything using readline, joe, vim etc.
Xterm by default also generate improper sequences: \E[H i \E[F, which are proper
for FreeBSD console according to /etc/inputrc comment.
Add to ~/.Xresources:
xterm*VT100.translations: #override \
<Key>Home: string(0x1b) string("OH") \n\
<Key>End: string(0x1b) string("OF") \n\
~@Num_Lock <Key>KP_Home: string(0x1b) string("OH") \n\
~@Num_Lock <Key>KP_End: string(0x1b) string("OF")
Will review for Fedora Core 5 development. It would be a good idea to
get this changed in upstream xterm by filing a bug report in Xorg bugzilla
however, to minimize the differences between upstream xterm.
I was a little wrong - xterm by default do generate proper sequences for
home/end when in so called "application cursor keys" mode, which is turned on by
every console application which support cursor keys.
We can check if xterm is in application mode by using Ctrl-Middle-Click on its
window. When there's only shell active this application mode is not turned on.
But if we start any ncurses application this mode will turn on automatically.
We can check this by the following minimal ncurses program:
This will enter application mode for 10 seconds.
So, the proper workaround for this bug is to disable translations completely, by
adding a one line to ~/.Xresources
Also there is no bug in xterm.
This does appear to be "fixed" with xterm-205-1 in rawhide-20051013 - at least the
home / end keys seem to generate the correct sequences in vi, less, and
an ncurses app (dialog), with the 'Application Cursor Keys' enabled / disabled.
From User-Agent: XML-RPC
xterm-205-1.FC4 has been pushed for FC4, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.