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

["Eli Zaretskii" <eliz@elta.co.il>]

> From: "Stefan Monnier" <monnier+gnu.emacs.help/news/@flint.cs.yale.edu>
> Newsgroups: gnu.emacs.help
> Date: 28 May 2003 13:53:12 -0400
> 
> > Yes, but the bug might be a design bug.  If that is so, we cannot tell
> > users "please wait for a few years until we redesign the darn thing."
> 
> Of course, but I haven't seen such a thing w.r.t binding-non-ASCII-keys
> and unibyte.

I'm not sure, but my observation was of a more general nature, since
the part of your message to which I was referring seemed to state a
very general principle.

> We're talking about adding a unibyte-cookie, right ?
> So we can assume that adding a coding-cookie is an acceptable cost
> if it saves us from a unibyte-cookie.

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.

> Setting the unibyte cookie doesn't either always solve the problem.

That's true.  IIRC, that is why the manual mentions both.

> Right now I know of no case where setting the unibyte cookie solves
> the problem while setting the keyboard-coding-system doesn't, which
> is why I suggest we recommend setting the keyboard-coding-system.

What about the order of settings Mule-related things, as I mentioned
above?