Bug 135505

That's an X library problem (Debian's been struggling with
it - I'm not sure if it's solved).

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.

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.

The color side effect is due to overwriting the existing resources. 
You generally want to use C< xrdb -merge .Xresources >

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.