strange keymap bugs

strange keymap bugs

[Colin Walters]

Hi,

I'm hoping a keymap guru can track this one down for me:

emacs -q --no-site-file 
M-x ibuffer

Then go to the "Operate" menu.  On my system, the option which should be
labeled "Kill" (`ibuffer-do-delete') is instead labeled "Apply Patch".

This has actually been happening for quite a while (like months), but I
kept thinking it was some weirdness on my system or a bug in ibuffer. 
I'm now pretty sure it's not either of those.

And, even stranger, move point up to the "[ Default ]" filter group
name, and pull down the "Operate" menu again.  On my system, the
toplevel "Operate", "View", and "Mark" menus now each contain themselves
as two submenus!

The "[ Default ]" filter group name *does* have a `keymap' property; but
this is just supposed to override those specific entries in the buffer's
local map, correct?

Re: strange keymap bugs

[Stefan Monnier]

> I'm hoping a keymap guru can track this one down for me:
> 
> emacs -q --no-site-file 
> M-x ibuffer
> 
> Then go to the "Operate" menu.  On my system, the option which should be
> labeled "Kill" (`ibuffer-do-delete') is instead labeled "Apply Patch".

I cannot reproduce this here.

> And, even stranger, move point up to the "[ Default ]" filter group
> name, and pull down the "Operate" menu again.  On my system, the
> toplevel "Operate", "View", and "Mark" menus now each contain themselves
> as two submenus!
> 
> The "[ Default ]" filter group name *does* have a `keymap' property; but
> this is just supposed to override those specific entries in the buffer's
> local map, correct?

Emacs does not really know how to merge two menus that way.
What you have to do instead is have your text-local map hide the
buffer-local menu and replace it with another one (which has
the same name but another binding).
This is a limitation of the current code in keyboard.c, AFAIK.


	Stefan

Re: strange keymap bugs

[Richard Stallman]

    Then go to the "Operate" menu.  On my system, the option which should be
    labeled "Kill" (`ibuffer-do-delete') is instead labeled "Apply Patch".

That failure does not happen for me now.

    And, even stranger, move point up to the "[ Default ]" filter group
    name, and pull down the "Operate" menu again.  On my system, the
    toplevel "Operate", "View", and "Mark" menus now each contain themselves
    as two submenus!

That does happen.

    The "[ Default ]" filter group name *does* have a `keymap' property; but
    this is just supposed to override those specific entries in the buffer's
    local map, correct?

For the keyboard, it overrides some bindings, but I think that making
two submenus is normal behavior in a menu when there are multiple
bindings for the same menu item.  There is no code to merge the
different keymaps to make one menu, and I am not sure that would be
the right thing in general, even if it is what you want in this case.

Re: strange keymap bugs

[Colin Walters]

On Mon, 2002-05-20 at 10:48, Richard Stallman wrote:
>     Then go to the "Operate" menu.  On my system, the option which should be
>     labeled "Kill" (`ibuffer-do-delete') is instead labeled "Apply Patch".
> 
> That failure does not happen for me now.

Hmm.  Strange.  I will try to track this down, then.

> For the keyboard, it overrides some bindings, but I think that making
> two submenus is normal behavior in a menu when there are multiple
> bindings for the same menu item.  There is no code to merge the
> different keymaps to make one menu, and I am not sure that would be
> the right thing in general, even if it is what you want in this case.

Ah.  So the solution is just to not set the keymap parent, and then
there will be no duplicate menu keybindings.  I don't know why I did
that in the first place; I think it was because I was originally using
the `local-map' property, but that brought its own problems.

Anyways, it works now.  Thanks!