Bug 141675 - ALT-f inputs character rather than control code
ALT-f inputs character rather than control code
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xterm (Show other bugs)
3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-02 15:48 EST by Thomas Fitzsimmons
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-11 10:11:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Thomas Fitzsimmons 2004-12-02 15:48:00 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
In bash, pressing ALT-f should move the cursor forward one word.  With
this version of xterm, it instead inserts �.


Version-Release number of selected component (if applicable):
xterm-192-1

How reproducible:
Always

Steps to Reproduce:
1. open xterm
2. press ALT-f


Actual Results:  � is entered at prompt

Expected Results:  cursor should jump to next word

Additional info:
Comment 1 Mike A. Harris 2004-12-03 13:05:30 EST
Hmm, now that I think about this one some more, I think this is
an intentional upstream xterm behaviour change which can be
configured in order to get the deprecated legacy behaviour back.

I'm not 100% sure of this however, but it seems to ring a slight
bell.  I'll have a look through previously reported xterm bugs
to see if I can find any similar issues, and if not I'll add
the xterm author to CC for his thoughts.

Thanks Tom
Comment 2 Thomas E. Dickey 2004-12-04 12:31:50 EST
The � doesn't look familiar (perhaps that's an interpretation,
since the locale noted is non-UTF-8).

Most of the recent problem reports relating to Alt have been
due to some problems with the X libraries which make the Alt
(Meta) key now longer work as reliably as it did.
Comment 3 Robert Spier 2005-01-02 22:45:27 EST
A little googling finds this similar issue:
  http://lists.debian.org/debian-user/1998/04/msg00927.html
which can be worked around by setting the following resource:
  XTerm*eightBitInput: false

on the down side, this means the xterm can't be used for direct 8 bit
input (although iirc, using the compose key will still work).  On the
positive side, the Alt/Meta emacs bindings work again.
Comment 4 Thomas E. Dickey 2005-01-03 20:02:56 EST
There's also metaSendsEscape
Comment 5 Jonathan Underwood 2005-01-16 19:31:17 EST
xterm seems quite broken with respect to the Alt key currently. Alt-f
and Alt-x give strange characters rather than sending the expected
control string, which breaks emacs and command line editing amongst
other things. The fix in Comment #3 won't work, XTerm*eightBitInput:
false is the default.
Comment 6 Jonathan Underwood 2005-01-17 11:59:55 EST
That'll teach me to be a sceptic, the fix mention in Comment #3 does
indeed work (I'd forgotten to xrdb). See also Bug 13505.
Comment 7 Jonathan Underwood 2005-01-17 17:38:15 EST
Sorry, I mean Bug 135505 in Comment #6
Comment 8 Mike A. Harris 2005-04-11 10:11:36 EDT
Fixed in rawhide xterm.

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