Re: emacs -nw in UTF-8 xterm does not work
Vincent Lefevre wrote:
: Do they work in Mutt? And in the shell? And in cooked mode?
In the shell: yes, as far as I can see.
In mutt: Umlaute are displayed correctly, but editing
mails does not work since I use emacs -nw. That's the
reason for my post. In mutt itself, e.g. when calling a function
that wants input, those characters can be entered.
Those characters also work for an ncursesw program that I'm
writing, and apparently produce the correct two-byte sequence
in my xterm. The Alt key (which I use as Meta) produces an
Escape prefix for any character.
: In fact, under Debian, you shouldn't need anything. For instance,
: if I type "emacs -q blah" in a uxterm, the status bar says:
: -uuu:---F1 blah All L1 (Fundamental)---------------------
: This is worth trying, in case the problem is due to some .emacs code.
Here's my status line (emacs 21.4):
$ emacs -nw -q blah
--uu:---F1 blah (Fundamental)--L1--All--------------------
: You should also give the output of "locale charmap", but I assume it
: will be UTF-8.
Henrik Enberg wrote:
: I'm able to compose ... ~/.Xresources:
: XTerm*metaSendsEscape: True
: XTerm*eightBitInput: False
I have added metaSendsEscape via xrdb -merge, but it had no
effect; in fact, the Alt-key had been sending escape before.
The problem seems to be, however, that
Meta - " - a
is also viewed by Emacs as an escape sequence, since the
dec 195 164/oct 303 244/hex c3 a4
of the Umlaut-a is apparently seen as
M-C (128 + 67 = 195) Capitalize-word
and perhaps also as
M-$ (128 + 36 = 164) Ispell-word
but the latter is not evident since after a word has been
capitalized the cursor is not on a word-character and the
function ispell-word has no effect.
So, I guess the problem is to get Emacs to view eight-bit
characters not as ESC something, but take them for their
As far as I can see, I have no active resources in my ~/.emacs
that could affect eight-bit input or character conversion in any
way; all are commented out.
Claus Fischer <email@example.com>