[Top][All Lists]

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

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

From: Stefan Monnier
Subject: Re: global-set-key [? \ M-ö]
Date: 28 May 2003 13:53:12 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

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

>> In the OP's case, I'm pretty sure the problem is that Emacs does not
>> properly set the keyboard coding-system.

> IIRC, there's more here than meets the eye.  Binding non-ASCII keys in
> a .emacs requires that (a) Emacs reads the key correctly from the init
> file and converts it to the internal representation that the user
> meant, and (b) that keyboard decoding produces a code that matches
> what was read from the init file.  It could be a bit tricky to satisfy
> both in a given language environment, since .emacs files generally
> don't have coding cookies.

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.

> Also, if I'm not mistaken, non-ASCII keys
> with modifiers are very hard to express unless you go unibyte.

I've never heard of any such difficulty.  [?\M-é] works fine here.
Oh wait, you're probably referring to "\M-é", which probably won't work,
indeed.  But the "keys in a string" thingy should best be forgotten
anyway: either use a vector or use `kbd'.

>> I don't think the manual should encourage to use workarounds (e.g. set
>> the unibyte:t cookie in your .emacs) rather than real fixes (set the
>> keyboard coding system properly).

> Unless setting keyboard coding system doesn't always solve the
> problem, that is.

Setting the unibyte cookie doesn't either always solve the problem.
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.
Of course, there might be cases where a unibyte-keyboard with
unibyte-.emacs works better, but I haven't seen them yet.


PS: BTW, when I say keyboard-coding-system I also mean locale-coding-system
(since that's what is used in X and in W32 for the keyboard events).

reply via email to

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