Re: global-set-key [? \ M-ö]

[Stefan Monnier]

> My failing memory keeps telling me that a coding cookie was not always
> enough, e.g. if the various language-environment specific aspects are
> set up _after_ the non-ASCII keybinding is read.  Again, I might be
> out of touch with the current codebase.

But assuming the coding-system of the file is the same as the one of the
keyboard, the only possible problem is if reading the .emacs (and other
things) end up changing the behavior of that coding-system.
Most coding-systems have an immutable behavior.  The only exception I know
of is coding-systems that do some form of unification upon decoding
and might unify into different charsets at different times.

I guess I could build a setup where the problem manifests itself, but
I don't know how common it is and I suspect that any such setup would
require significant changes to make it work with a unibyte .emacs.

...

Hmmm.... it seems that there's one case where a unibyte answer might
make sense: the user wants to use latin-9 but also has some latin-1 files
and doesn't want to suffer from the corner cases of encode-only
unification, so he turns on decode-unification in his .emacs.  His keyboard
coding system is set to latin-9, but unification translates most of those
to latin-1 chars, so his .emacs should be read as latin-1 for most
non-ASCII keybindings.  A unibyte cookie in the .emacs won't directly help,
but if you additionally set the keyboard-coding-system to nil, it might
end up working.


        Stefan