Bug 135505 - xterm / emacs -nw / Alt != Meta
xterm / emacs -nw / Alt != Meta
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: xterm (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
:
Depends On:
Blocks: FC4Target
  Show dependency treegraph
 
Reported: 2004-10-13 01:24 EDT by Satish Balay
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-03-08 17:16:43 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 Satish Balay 2004-10-13 01:24:48 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041012

Description of problem:
When emacs is invoked within 'xterm' (with -nw) 'Alt' key doesn't
behave as emacs 'Meta-'

Version-Release number of selected component (if applicable):
xterm-192-1, emacs-21.3-15

How reproducible:
Always

Steps to Reproduce:
1. install FC2T3/Rawhide
2. start xterm
3. use 'emacs -nw' within the xterm
4. try 'M-x' with Alt-X
    

Actual Results:  Wierd chars appear instead of the emacs function M-x

����

Expected Results:  emacs M-x behavior.

Additional info:

Alt-x behaves as M-x with:

- emacs with x-display 
- 'emacs -nw' within gnome-terminal
Comment 1 Thomas E. Dickey 2004-10-15 15:21:27 EDT
That's an X library problem (Debian's been struggling with
it - I'm not sure if it's solved).
Comment 2 KOROSI Akos 2004-11-30 14:03:27 EST
Similar problem here (FedoraCore3, xterm-192-1):
Alt+<something> key combinations does not work if xterm is started
with UTF-8 (default in FC3). This is extremly annoying when I use mc
(Midnight Commander) and I want to use Alt+<something> key combinations.
When I start xterm with -en "ISO 8859-1", then the key combinations
are ok but mc looks horrible.
Comment 3 Jonathan Underwood 2005-01-17 17:36:19 EST
This seems to be a problem with xterm (not emacs). The following
workaround fixes the issue:

a) Add "XTerm*eightBitInput: false" to .Xresources in $HOME
b) run xrdb .Xresources

However, as a side effect, xterm's background is now set to white, as
opposed to the gray that is normally the case. Note that part (b)
needs to be done everytime you log in, as .Xresources isn't normally
resourced by gnome.

There is a second issue with emacs and FC3 xterms though: the old
DEL/^H/^? problem. As it stands currently, both backspace and C-h send
^H in xterm. Emacs is fine with this for the backspace key, which as
expected
deletes the character to the left of the cursor. However, C-h no
longer gives you access to help. Back to the old discussion as to
whether this is an emacs or xterm issue though. 

For what it's worth stty -a in an xterm shows that erase is ^H,
whereas in a
gnome-terminal erase is set to ^? (ie. DEL). Surely there should be
some consistency here, one way or the other? Both are reading the same
terminfo of course, so it's not an issue there. Doing stty erase '^?'
in xterm doesn't fix anything, as backspace still returns ^H. Quite
what is going on escapes me. I thought this problem had been fixed a
LONG time ago. As far as I understand, the accepted way of doing
things was to have backspace return ^?. This may not be an xterm bug,
but I'm unsure where it should be reported.

Comment 4 Robert Spier 2005-01-17 19:49:51 EST
The color side effect is due to overwriting the existing resources. 
You generally want to use C< xrdb -merge .Xresources >
Comment 6 Dale R. Worley 2005-03-08 14:32:27 EST
I've finally gotten a handle on how to fix these problems.  In short, put this
in your .xsession file:

# Fix the X resources so xterm works correctly.
# eightBitInput allows the Alt key to function as Meta.
# VT100.Translations sets "<--" to generate DEL and "Delete" to generate C-d.
# ttyModes tells xterm to start with "stty erase ^?".  (When Emacs starts,
# it will see the "stty erase" value, and set tty-erase-char to 127, which will
# prevent command-line in startup.elc from setting normal-erase-is-backspace
# to t.)
xrdb -merge <<EOF
XTerm*eightBitInput: false
*VT100.Translations:	#override \
	<Key>Delete: string(0x04) \n\
	<Key>BackSpace: string(0x7F)
XTerm*ttyModes: erase ^?
EOF

Note that the punctuation is exactly as it appears above.

Setting eightBitInput causes xterm to use the Alt key as a Meta modifier.

The VT100.Translations value tells xterm to interpret the "<--" (Backspace) key
as generating code 0x7F (DEL), and the "Delete" key as generating 0x04 (C-d).

The critical and nasty point is the ttyModes value.  When xterm starts up, the
"stty" state of the pseudotty it is using gets set somehow.  (And I the default
setting changed between FC 2 and FC 3.)  But xterm will execute the settings in
the ttyModes property, so this ensures that the erase character is DEL, not C-h.
 Once "stty erase" is set correctly, when Emacs starts in the xterm window, it
will set the tty-erase-char value to 127 (not 8), which will prevent the
function command-line in startup.elc from setting normal-erase-is-backspace to
t.  So 0x7F (generated by the <-- key) will be delete-backward-char, 0x04
(generated by the Delete key) will be delete-char, and 0x08 (generated by
Ctrl+H) will be help-command.

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