Bug 48783 - RFE: Make alt-left/right jump words by default
RFE: Make alt-left/right jump words by default
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
7.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
: FutureFeature
: 62777 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-07-11 15:28 EDT by Mike Schiraldi
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-01-23 13:47:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Mike Schiraldi 2001-07-11 15:28:42 EDT
A lot of people are used to being able to press Ctrl-left/right or Alt-
left/right to jump a word at a time in a body of text. I've accomplished 
this by adding

"\e[5C": forward-word
"\e[5D": backward-word
"\e\e[C": forward-word
"\e\e[D": backward-word

to my .inputrc and

XTerm*vt100.translations: #override\n\
Meta<Key>Right: string(0x1b) string(0x1b) string("[C") \n\
Meta<Key>Left: string(0x1b) string(0x1b) string("[D") \n

to my .Xdefaults.

Please consider making these preferences a standard part of your 
distribution. It's nice to jump a word at a time when you're editing a 
long command line, and having to use Alt-B and Alt-F is awkward.
Comment 1 Bill Nottingham 2001-07-19 16:06:57 EDT
Added in setup-2.5.2-1 to inputrc. Assigning to XFree86.
Comment 2 Mike A. Harris 2001-07-24 02:49:31 EDT
Added to xterm resources in rawhide 4.1.0-0.9.3
Comment 3 Achim Settelmeier 2001-12-11 19:51:36 EST
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~.
Comment 4 Joe Burpee 2002-01-05 23:56:52 EST
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.)
Comment 5 Mike Schiraldi 2002-01-07 15:30:06 EST
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.
Comment 6 Joe Burpee 2002-01-07 19:23:28 EST
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.
Comment 7 Mike A. Harris 2002-01-23 13:43:23 EST
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.
Comment 8 Mike A. Harris 2002-01-23 13:47:53 EST
See also:

bug #58031
bug #58713
bug #49315
Comment 9 Mike A. Harris 2002-01-23 14:14:39 EST
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.

Comment 10 Mike Schiraldi 2002-01-23 14:17:39 EST
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.
Comment 11 Mike A. Harris 2002-01-23 15:23:20 EST
> 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.

Comment 12 Mike Schiraldi 2002-01-23 15:39:04 EST
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.
Comment 13 Hans de Goede 2002-04-05 10:04:04 EST
*** Bug 62777 has been marked as a duplicate of this bug. ***

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