8-bit input as meta key for emacs -nw

8-bit input as meta key for emacs -nw

[Cilantro]

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.

Re: 8-bit input as meta key for emacs -nw

[Stefan Monnier]

> 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.

Could you also indicate what kind of Emacs build it is (i.e. if it's the
Emacs provided by SuSe or RedHat or if it's the official Emacs straight
from the horse's mouth: packagers tend to screw things up in subtle ways
like that).

> 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?

(set-keyboard-coding-system nil)


        Stefan

Re: 8-bit input as meta key for emacs -nw

[Cilantro]

I believe my problem is that e.g. M-v is being interpreted in
a terminal window as (quote [246]) rather than "\366".  So an
equivalent question is how does one force an "emacs -nw" session
to interpret meta keys as e.g. \366 rather than [246]?

Re: 8-bit input as meta key for emacs -nw

[Cilantro]

>> (set-keyboard-coding-system nil)

THANK YOU!  This fully resolves the problem.

>> Could you also indicate what kind of Emacs build it is.

Vanilla SuSE 9.0 install from their RPM; emacs-version says:
	GNU Emacs 21.3.1 (i586-suse-linux, X toolkit, Xaw3d scroll bars)
	of 2003-10-02 on D45

Thanks again!