Bug 58031 - xterm app-defaults breaks Home/End in terminfo apps
Summary: xterm app-defaults breaks Home/End in terminfo apps
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86   
(Show other bugs)
Version: 7.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
: 58713 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2002-01-06 16:14 UTC by Joe Burpee
Modified: 2007-03-27 03:50 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-01-23 19:19:41 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Joe Burpee 2002-01-06 16:14:53 UTC
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.
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.

Comment 1 Mike Schiraldi 2002-01-08 15:20:20 UTC
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

Comment 2 Joe Burpee 2002-01-08 19:09:03 UTC
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.)

Comment 3 Mike A. Harris 2002-01-23 19:19:36 UTC
*** Bug 58713 has been marked as a duplicate of this bug. ***

Comment 4 Mike A. Harris 2002-01-23 19:27:43 UTC
this is now fixed in Rawhide X 4.2.0-2.4

Note You need to log in before you can comment on or make changes to this bug.