Bug 48783

Added in setup-2.5.2-1 to inputrc. Assigning to XFree86.

Added to xterm resources in rawhide 4.1.0-0.9.3

Looks like the change of /usr/X11R6/lib/X11/app-defaults breaks other 
key bindings declared earlier in that file (line 148+). 

In my case, the Home and End keys translate into ^[[H and ^[[F 
instead of ^[[1~ and ^[[4~.

Yes /usr/X11R6/lib/X11/app-defaults is now broken, since it contains two
#overrides for the same translation resource.  Most of the key translations are
now lost.  Easy fix is just to join the translations into one big one: delete
the 2nd #override line, and add '\' to end of preceding line.

BTW, losing the correct Home/End translations means that xterm uses escape
sequences that disagree with the `xterm' terminfo.  This doesn't affect
bash/readline, since multiple bindings are given in /etc/inputrc.  However
Home/End *are* broken in termcap/terminfo-dependent apps -- e.g. mutt or less
running in an xterm.

There are workaround keys, but Home/End are pretty basic, and documented as
working by both mutt and less.  Also the bad Home/End sequences actually produce
other effects in mutt, fortunately non-destructive.  **There may be other apps
that are not so lucky.**

The sad part of this is there never was any bug other than the one introduced by
the "fix".  The original request was only a nice-to-have that should not have
appeared in bugzilla.  In fact the requestor demonstrated that users could do it
themselves.  The Meta-b and Meta-f that the requestor found "awkward" are
standard Emacs bindings, and probably less awkward than reaching for arrow keys.

Come on guys.  You must have better things to do.  This is a waste of everbody's
time.  (And it sure doesn't say much for quality control.)

This is a matter of opinion that will of course be ultimately decided by RH's UI
engineers, but i'll provide a bit of explanation of why i think that 
ctrl+arrows are significantly more convenient than meta-b and meta-f.

In my experience, many users use the up and down arrows to move through their
command history, and the left and right arrows to move the cursor around a
single command line. This argument is based on that premise.

I'm one of those users, and so my right hand is already positioned on the arrow
key cluster. It's really easy to hit LCtrl with just about any part of my left
hand while continuing to use the right hand to hit arrows. Not only can i do
this quickly, but more importantly, i can do it without losing mental focus.

However, on most common keyboards, left Alt can't be "mashed" this way. There
are only two ways i've found to press alt-b or alt-f: 

- Curl my left thumb inward to press and hold Alt, then stretch my fingers way
over to hit the other key. Try this right now with Alt-B, and take a good look
at what your poor fingers have to do in order to hit that key combination.

- Use some part of my left hand to press and hold Alt, and use my right hand to
press B or F. These are both "left hand" keys, and my right hand's muscle memory
doesn't "know" where they are -- i need to look down and find the keys. 

The argument that this is "standard emacs behavior" is flawed -- this behavior
was designed for use with computers whose Meta key was in the position that Left
Ctrl or ` keys are on most keyboards, and when arrow keys often either did not
exist or did not work over a given terminal.

Times change, and applications evolve. For example, the textbox i'm typing into
right now recognizes Ctrl+Arrows to jump words, but not Meta-B/F.

That said, i'm not an expert on X11 config files, and perhaps my fix is broken.
But instead of throwing the idea away, perhaps someone with more experience with
these files can post a better patch that provides the same functionality.

I'd better clarify.  I'm not saying your "fix is broken".  It's fine
exactly as presented; the ultimate implementation was broken.  Also, I'll take
your point regarding awkwardness; I'm no expert on ergonomics.  And I think you
properly characterize the issue as a matter of opinion, which makes the RFE
label particularly relevant.

On the matter of "standard Emacs": I was referring to the fact that bash
supports two sets of standard bindings, one based on Emacs, the other on vi.  (I
was not referring to Emacs per se, which btw does support such use of arrow
keys.)  Any user is quite free to extend or amend these two default setups, as
you have demonstrated, and can also mirror such changes in X resources if
desired.

What concerns me (and I think should concern you as RH user as well as the one
to whom the "fix" is attributed) is the qualty assurance issue.  Your non-bug
RFE on 7.1 was turned into a real bug in 7.2.  This wasted my time (and probably
that of some others).  You'll note above that I was not the first one to report
the
breakage.  All this points to weakness in RH procedures, and probably bugzilla
itself.

I have posted a new bug (58031) re 7.2, which I think is relevant to the current
situation.

I agree.  This non-bug enhancement has caused a lot of people grief,
and was not noticed.  Officially, we provide xterm, but we do not
support xterm.  This enhancement was made purely trying to be
helpful to a reasonable sounding user request.

It has turned into a lot of problems, and I am more inclined to
disable it now, and set it back the way it was before.

See also:

bug #58031
bug #58713
bug #49315

Ok, this bug is really causing me a big PITA, and hours of lost
time.  I am removing the feature that was added.  Someone who
cares about this feature enough to troubleshoot all angles of
the Xterm resources file and make sure everything works and works
sensibly, should instead send patches to XFree86.org.  I will
only accept bug fixes to these files from now on, and probably
only if XFree86.org has accepted them also.

I'm sure you'll both agree that this new change, shows the strengths
of Red Hat's procedures and dedication to quality, and also in
sticking closer to XFree86.org releases.

I don't have sufficient privileges to view #49315, but the other two bugs are
both fixed by my patch from #58031:

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


I dispute the claim that "This non-bug enhancement has caused a lot of people
grief." It would be more accurate to say, "The engineer who modified
app-defaults did not know what they were doing, and broke something while adding
your enhancement." There's nothing inherently wrong with adding support for
Ctrl-left/right. The problem came from the fact that, in adding this support, a
Red Hat engineer turned off all the default translations. Turn them back on with
the above patch, and the problems should all go away.

> I dispute the claim that "This non-bug enhancement has caused a lot
> of people grief."

You can dispute the claim all you wish, and it doesn't make a lick of
difference.  Prior to this enhancement being applied, things worked.
After it was applied, things broke.  This caused problems.  Where
they stemmed from, and how it came to be makes no difference to me.
The fact is that we do not support xterm, and I kindly went out of
my way to do YOU a favour, since it seemed reasonable to me.  That
kindness created a bug, which I have lost a lot of time over now for
some relatively minor feature request.

> It would be more accurate to say, "The engineer who modified
> app-defaults did not know what they were doing, and broke
> something while adding your enhancement."

And for my kindness, I get insulted.  *I* am the one who did this
enhancement for you, and have now been screwed for it and insulted.
I will guarantee you, that because of this, you will not see this
change applied by me to future releases - I am likely to be screwed
over again, and then insulted again.  I don't have time for this
type of waste-of-my-time-trivia by rude people.

For what it's worth, i did not mean to be rude or insulting. 

I've seen your posts to various mailing lists, and i know that you're a
talented and qualified engineer. However, you made a mistake. It happens;
you're human. We all make mistakes. I certainly did not mean for my
statement to hurt your feelings or make you look bad, and i apologize if it
did.

But i will set the record straight.

The proper way to add new XTerm translations is to add to the preexisting
"*VT100*translations" block. If you add a new block, it turns off all the
preexisting ones. Whoever applied my patch did so in a new block, instead of
appending it to the preexisting one. This action is what broke everything. 

Again, i feel terrible that you lost so much time on this problem, and i
hope that you did not take much heat from your supervisors over it. But the
mistake had absolutely nothing to do with this RFE.

*** Bug 62777 has been marked as a duplicate of this bug. ***