bug#53910: [External] : bug#53910: 29.0.50; context-menu-mode breaks help in read-only buffers

[Stefan Monnier]

>>>  (defvar context-menu-entry
>>>    `(menu-item ,(purecopy "Context Menu") ,(make-sparse-keymap)
>>> -              :filter ,(lambda (_) (context-menu-map)))
>>> +              :filter ,(lambda (_) (unless help-buffer-under-preparation
>>> +                                     ;; No need to build menu to describe 
>>> keys
>>> +                                     (context-menu-map))))
>>>    "Menu item that creates the context menu and can be bound to a mouse 
>>> key.")
>> FWIW, I find this hideous.  `mouse.el` should not depend on `help-*` 
>> variables.
> I know, but there are too many problems when help functions are trying
> to build the context menu in a non-displayed buffer.

Those are bugs in the context-menu functions that need to be fixed
because they'll bite us sooner or later in other cases anyway.
In a sense, we should be happy to have such an easy way to trigger those
bugs ;-)

> Is there another way to prevent this?

I think a slightly cleaner way (if you want to keep such a workaround
rather than chase&fix the underlying bugs) is to move the var to
`mouse.el` and call it `inhibit-context-menu`, and then let-bind at the
appropriate place with a prominent comment explaining why we're using
such a hack.

> Maybe (kill-buffer (window-buffer <WINDOW>)) has the same effect
> when used in any window, but (bury-buffer (window-buffer <WINDOW>))
> definitely should be called in the required window,

Indeed, there are several function that need the right `selected-window`
and where you can't pass an explicit window instead, and `bury-buffer`
is one of them.


        Stefan