Bug 141675

Summary:	ALT-f inputs character rather than control code
Product:	[Fedora] Fedora	Reporter:	Thomas Fitzsimmons <fitzsim>
Component:	xterm	Assignee:	Mike A. Harris <mharris>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3	CC:	dickey, rspier, xgl-maint
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-04-11 14:11:36 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Thomas Fitzsimmons 2004-12-02 20:48:00 UTC

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 18:05:30 UTC

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 17:31:50 UTC

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-03 03:45:27 UTC

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-04 01:02:56 UTC

There's also metaSendsEscape

Comment 5 Jonathan Underwood 2005-01-17 00:31:17 UTC

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 16:59:55 UTC

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 22:38:15 UTC

Sorry, I mean Bug 135505 in Comment #6

Comment 8 Mike A. Harris 2005-04-11 14:11:36 UTC

Fixed in rawhide xterm.