bug#9923: 24.0.91; `where-is' does not find recentf menu items (cmds, not files)

[Juri Linkov]

>>> I think it would be more "obviously correct" if we switched to
>>> (window-buffer (posn-window (event-end click))) instead.
>>
>> Will do this if a simpler solution below is not suitable.
>
> I think the hunk above (and the one before that) is a good change
> regardless of this specific bug: it doesn't make sense to use
> `posn-point` without making sure we're in (window-buffer (posn-window ...)).

So this fix is pushed to emacs-28.

> Hmm... taking a second look at the `mouse.el` file, I think the problem
> is rather than the menu-item has an nominal/default/static binding of
> `ignore`.  So I guess the `:filter` isn't run to try and look for
> `ignore` in the dynamically-generated map but instead it's run later
> (when `where-is-internal` checks that the binding it found is real).
>
> So maybe another way to avoid running the filter is with the
> patch below.
>
> --- a/lisp/mouse.el
> +++ b/lisp/mouse.el
> @@ -513,7 +513,7 @@ context-menu-ffap
>    menu)
>  
>  (defvar context-menu-entry
> -  `(menu-item ,(purecopy "Context Menu") ignore
> +  `(menu-item ,(purecopy "Context Menu") ,(make-sparse-keymap)
>                :filter (lambda (_) (context-menu-map)))
>    "Menu item that creates the context menu and can be bound to a mouse key.")

I confirm that it prevents `where-is-internal` from calling `context-menu-map`,
and everything else works fine, but I'm not sure how this change fits
into the overall design of the menu bindings.  Maybe, `make-sparse-keymap`
means that `context-menu-entry` contains an empty menu initially.