Hide Forgot
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. How Reproducible: 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. OR 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. Alternative fixes: 1. Delete the new translation in /usr/lib/X11/app-defaults/XTerm. (It's an unnecessary frill.) 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 *VT100*saveLines: 2500
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