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 sure. :-) 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.
