help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

8-bit input as meta key for emacs -nw


From: Cilantro
Subject: 8-bit input as meta key for emacs -nw
Date: Wed, 10 Dec 2003 10:05:45 -0800

When logged into a remote machine, I run emacs inside an xterm window
using "emacs -nw".  Starting with emacs 21, I'm having trouble getting
8-bit data to be interpreted as a meta key; instead of M-d I get an
a-umlaut.  I have access to 4 Linux machines which behave differently:
     Machine 1 (RH 9; emacs 21.2):
        LANG=en_US.UTF8 produces accented characters;
        LANG=en_US gives meta key.
     Machine 2 (RH 9; emacs 21.2): Always gives meta key.
     Machine 3 (Debian 3; emacs 21.2): Always gives meta key.
     Machine 4 (SuSE 9; emacs 21.3): Never gives meta key.
So far as I can tell, the environments on all 4 machines are the same,
but I don't understand all the new (to me) locale and mule support.

Taking the SuSE machine as an example, there is still some LANG
dependence:
        LANG=en_US.UTF8 uses encoded-kbd-self-insert-ccl
        LANG=en_US users encoded-kbd-self-insert-iso2022-8bit
Presumably, I want to use the esc-map instead.

Can someone tell me a reliable way to force emacs to interpret 8-bit
characters the old way, that is, as though the meta key were held down?
I'm willing to disable international character support if necessary.
The only kluge I've been able to come up with is to reprogram all the
8-bit keys I use to not self-insert, but rather map to their meta
equivalents, but there's surely a better way.

Again, this is only an issue for "emacs -nw"; emacs in a separate window
works fine.  I'm considering switching from RH to SuSE on my own
machine, but want to get this resolved first if possible.

Thanks.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]