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

[Juri Linkov]

>>  (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.  Is there another way
to prevent this?  Recently this was changed:

  -  `(menu-item ,(purecopy "Context Menu") ignore
  +  `(menu-item ,(purecopy "Context Menu") ,(make-sparse-keymap)

to prevent where-is-internal from running context-menu-map by
describe-mode in the wrong buffer, but this was not enough.

>> While it's possible to use the 'window' argument in all functions used
>> in window-safely-shrinkable-p, tab-line functions use functions that
>> don't accept the 'window' argument, e.g. current-buffer, kill-buffer.
>
> `window-buffer` is the function that returns the "current" buffer of a
> window.  As for `kill-buffer`, I'm not sure what window arg you'd like
> to use by I suspect (kill-buffer (window-buffer <WINDOW>)) is what
> you're after.

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, because `bury-buffer`
uses `nil` for the WINDOW args, e.g.:

      (set-window-dedicated-p nil nil)
      (switch-to-prev-buffer nil 'bury)