GNU bug report logs - #78945
30.1; C-x 4 4 and C-x 5 5 do not work with `dired-mouse-find-file'

Previous Next

Full log

View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 78945 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, alcor <at> tilde.club
Subject: bug#78945: 30.1; C-x 4 4 and C-x 5 5 do not work with `dired-mouse-find-file'
Date: Mon, 07 Jul 2025 20:01:24 +0300

>> Not sure how would be possible to handle double-clicks in this case:
>>
>>   C-x 5 5                 ;; other-frame-prefix
>>   <down-mouse-1>          ;; mouse-drag-region
>>   <mouse-1>               ;; mouse-set-point
>>   <double-down-mouse-1>   ;; mouse-drag-region
>>   <double-mouse-1>        ;; mouse-set-point
>
> Why not?

Ok, double-clicks should be handled as well.  For example,
image-dired defines:

  "<down-mouse-1>"   #'image-dired-mouse-select-thumbnail
  "<mouse-1>"        #'image-dired-mouse-select-thumbnail
  "<double-mouse-1>" #'image-dired-mouse-display-image

But currently `C-x 5 5 <double-mouse-1>` doesn't display
an image in a new frame.

>> `describe-key` uses
>>
>>   (and (not (memq mouse-1-click-follows-link '(nil double)))
>>        (> (length raw) 0)
>>        (eq (car-safe (aref raw 0)) 'mouse-1)
>
> Not really.  The relevant code is (in `help--read-key-sequence`):
>
>           (while
>               ;; Read at least one key-sequence.
>               (or (null key-list)
>                   ;; After a down event, also read the (presumably) following
>                   ;; up-event.
>                   (memq 'down last-modifiers)
>                   ;; After a click, see if a double click is on the way.
>                   (and (memq 'click last-modifiers)
>                        (not (sit-for (/ (mouse-double-click-time) 1000.0) t))))
>
> That also handles triple-clicks.
>
>> But I'm afraid that not exiting on <mouse-1> in
>> `display-buffer-override-next-command` would be too error-prone.
>
> The "normal" way to disable the override is by consuming it:
>
>                        ;; Reset display-buffer-overriding-action
>                        ;; after the first display-buffer action (bug#39722).
>                        (funcall clearfun)
>
> I'm not suggesting we leave the override active "indefinitely" for as
> long as no `display-buffer` used it, but I don't expect any serious
> problem if the override lingers a bit longer.

The only potential problem is mistyped keys or accidental clicks.
But since it's very rare then maybe this patch is ok:

diff --git a/lisp/window.el b/lisp/window.el
index ea102706ecb..a25af158a73 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -9673,9 +9680,9 @@ display-buffer-override-next-command
                      ;; But don't remove immediately after
                      ;; adding the hook by the same command below.
                      (eq this-command command)
-                     ;; Don't exit on mouse down event
-                     ;; in anticipation of mouse release event.
-                     (memq 'down (event-modifiers last-input-event)))
+                     ;; Don't exit on mouse down event in anticipation
+                     ;; of mouse release or double click event.
+                     (mouse-event-p last-input-event))
               (funcall exitfun))))
     ;; Call post-function after the next command finishes (bug#49057).
     (add-hook 'post-command-hook postfun)

Previous Next

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