GNU bug report logs - #53910
29.0.50; context-menu-mode breaks help in read-only buffers

Previous Next

Full log

Message #42 received at 53910 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Ergus <spacibba <at> aol.com>,
 Drew Adams <drew.adams <at> oracle.com>,
 "53910 <at> debbugs.gnu.org" <53910 <at> debbugs.gnu.org>
Subject: Re: [External] : bug#53910: 29.0.50; context-menu-mode breaks help
 in read-only buffers
Date: Sun, 13 Feb 2022 20:50:10 +0200

>> What worries me more is that the following idiom is not always safe:
>>
>>    (with-selected-window (or window (selected-window))
>>      body
>>      ...)
>>
>> because it might switch the buffer of the already selected window.
>
> IIUC you mean that it might make another buffer current?  But the whole
> idea of selecting a window is that it gets you in a consistent state
> where, for example, the window is the selected window of its frame which
> is also the selected frame and point returns the position of point of
> the selected window.  Everything else is of evil (on the Lisp level).

Indeed, what describe-bindings does by calling context-menu after
switching buffers is evil.  Here is another attempt to prevent this:

diff --git a/lisp/mouse.el b/lisp/mouse.el
index 4c0d455808..1ad6fd089b 100644
--- a/lisp/mouse.el
+++ b/lisp/mouse.el
@@ -541,7 +541,9 @@ context-menu-ffap
 
 (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.")

> I don't know why you need that idiom in tab-line.el but, for example,
> the completely misguided
>
> (defun window-safely-shrinkable-p (&optional window)
>   "Return t if WINDOW can be shrunk without shrinking other windows.
> WINDOW defaults to the selected window."
>   (with-selected-window (or window (selected-window))
>     (let ((edges (window-edges)))
>       (or (= (nth 2 edges) (nth 2 (window-edges (previous-window))))
> 	  (= (nth 0 edges) (nth 0 (window-edges (next-window))))))))
>
> should be written as
>
> (defun window-safely-shrinkable-p (&optional window)
>   "Return t if WINDOW can be shrunk without shrinking other windows.
> WINDOW defaults to the selected window."
>   (let ((edges (window-edges window)))
>     (or (= (nth 2 edges) (nth 2 (window-edges (previous-window window))))
> 	(= (nth 0 edges) (nth 0 (window-edges (next-window window)))))))
>
> So I'd urge you to rewrite the tab-line functions in a more safe way.

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.
But there is no problem for tab-line to select the already selected window
since it operates on windows.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.