Bug#266336: xterm changes meta-X to meta-8 in en_US.UTF-8 locale
On Wed, 2004-08-18 at 16:19, Thomas Dickey wrote:
> Perhaps you have a resource setting confusing things. I see the proper
> symbol (a lowercase "o" with a slash through it). The eightBitInput and
> metaSendsEscape resources related to "meta-X" (sending an escape character
> before the code).
Okay, I see -- pressing alt-X gives me the ø character in the shell
regardless of my encoding, yes. emacs knows to translate that character
back into M-x, though, which is why alt-X works in emacs in the
en_US.ISO-8859-1 locale. emacs ignores the locale when it does the
ø-to-M-x translation, though. In en_US.ISO-8859-1, ø is encoded as 0xf8
and emacs sees it as M-x. In en_US.UTF-8, ø is encoded as 0xc3, 0xb8,
and emacs sees it as M-c, M-8.
Setting metaSendsEscape makes emacs work properly, but (of course)
breaks composing characters for the shell.
So I'm inclined to call this an emacs21 bug instead; if emacs is going
to do this auto-translation of composed characters back into
M-sequences, it should respect the locale setting when it does it. (How
people are supposed to enter non-ASCII characters into emacs I'm not
It looks like I'm two for two for reporting a bug in random software
as an xterm bug -- very sorry for wasting your time; I should take more
care to investigate these bugs before I report them. AFAICS, this bug
should be reassigned to emacs21.