Description of Problem:
I guess this is a new bug in 7.2, although it's connected to "bug"
48783, which was actually an RFE for 7.1 that introduced a real bug.
/usr/lib/X11/app-defaults/XTerm now contains two translation #overrides, so
the important original translations are lost. This means that xterm
bindings for Home and End do not agree with the xterm terminfo. For
bash/readline the problem is masked by the multiple bindings in inputrc.
For termcap/terminfo-dependent apps (less, mutt, etc.) Home/End produce
the wrong escape sequences. E.g. End produces "F" (in part) which in
mutt means "flag message" and is fortunately not destructive, but it could
be worse in other apps.
Version-Release number of selected component (if applicable):
Still in XFree86-4.1.0-12 on rawhide.
Press ^V<Home> or ^V<End> in bash in an xterm. Compare to app-defaults.
Steps to Reproduce:
1. In an xterm, type `mutt';.
2. Press Home or End in a mailbox index.
3. Type '?' to check what correct bindings are supposed to be.
1. In an xterm, type `less <somefile>'.
2. Type `/qwerty' to search for string, and try to edit the string using
Home or End.
3. Type 'h' to check what correct bindings are supposed to be.
1. Delete the new translation in /usr/lib/X11/app-defaults/XTerm. (It's an
2. Merge the two translations into a single #override.
3. Change the xterm terminfo to match the broken xterm. (??)
4. Fix xterm source.
The main thing is: don't modify fundamental configuration files without
good reason. This thing was a totally avoidable waste of time.
Patch which seems to fix the problem:
--- /tmp/XTerm Tue Jan 8 10:13:15 2002
+++ /usr/lib/X11/app-defaults/XTerm Tue Jan 8 10:15:52 2002
@@ -172,12 +172,9 @@
Ctrl <Btn4Down>: scroll-back(1,line) \n\
Ctrl <Btn5Down>: scroll-forw(1,line) \n\
<Btn4Down>: scroll-back(5,line) \n\
- <Btn5Down>: scroll-forw(5,line)
-! Add word-left, word-right user suggested enhancement from bugzilla 48783
-*VT100*translations: #override \n\
-Meta<Key>Right: string(0x1b) string(0x1b) string("[C") \n\
-Meta<Key>Left: string(0x1b) string(0x1b) string("[D") \n
+ <Btn5Down>: scroll-forw(5,line) \n\
+Meta <Key>Right: string(0x1b) string(0x1b) string("[C") \n\
+Meta <Key>Left: string(0x1b) string(0x1b) string("[D")
! Provide plenty of scrollback
Yes thank you. I guess that would do it, at least for those who happen to
favour alternative #2. However, as I think you'll appreciate, it doesn't do
anything to fix the real problem.
(BTW, given what happens to patches when bugzilla forwards via e-mail,
it may be better just to post them as attachments. It could also simplify
things a bit for those working in console mode -- which may not matter
much in this case, since the patch is X-related.)
*** Bug 58713 has been marked as a duplicate of this bug. ***
this is now fixed in Rawhide X 4.2.0-2.4