Selon Benjamin Herrenschmidt <[EMAIL PROTECTED]>:
> On Sat, 2005-02-19 at 15:01 +0100, Denis Barbier wrote:
> > [Sorry for breaking this thread, but I am back from vacation and
> > the nameserver for my mail is down for the whole weekend]
> >
> > Benjamin, I cannot reproduce this bug; as emacs does not handle
> > ISO_Level3_Shift, my only bet is that something is wrong with
> > your modifiers. Can you please run
> > $ xkbcomp :0
> > and send me the server-0.xkb file generated by this command?
> > And what does xev display when you press ISO_Level3_Shift+q?
>
> Ok, thanks for the tip using xkbcomp that way, I think I found the
> problem, though it is still strange that xemacs behaves differently...
[...]
> The problem is that when the "fr" stuff overrides the "us" stuff, the
> second entry is not removed, and thus, the resulting map in the server
> looks like (from server-0.xkb):
>
> key <LALT> { [ ISO_Level3_Shift, Meta_L ] };
>
> Which causes emacs to interpret that key as an additional Meta instead
> of the other "Meta" key... Commenting out the stuff in the "us" keymap
> fixes it.
Absolutely.
Emacs and xemacs have a predefined list of keys that can behave as
modifiers. With your settings, <LALT> acts as a Meta-key when shifted,
so emacs treat it as a modifier key. In fact, your problem is not
related to XKB at all.
As you can imagine, both programs use slightly different algorithms
to compute this predefined list of modifier keys, which is why xemacs
works here but not emacs. IMO this bug can be closed unless someone
wants to report this issue upstream, but I am not sure whether there
is a solution to this problem without rewriting lots of code.
As a workaround (not tested), you can replace your definition by
key <LALT> {
type= "ONE_LEVEL",
symbols[Group1]= [ ISO_Level3_Shift ]
};
which is in fact what you want.
(This may give a warning about missing levels, you can ignore it)
--
Denis
