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

Package: emacs;

Reported by: Alcor <alcor <at> tilde.club>

Date: Wed, 2 Jul 2025 19:13:02 UTC

Severity: normal

Found in version 30.1

Fixed in version 31.0.50

Done: Juri Linkov <juri <at> linkov.net>

Full log


View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78945 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>, 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: Fri, 04 Jul 2025 09:42:07 +0300
>> > I just have a question regarding possible side effects: I understand
>> > that this change ignores `mouse-drag-region' events. I'm not sure
>> > whether it's possible to bind functions to these events, but if yes,
>> > wouldn't this preclude any commands/functions bound to
>> > `mouse-drag-region' from being affected by C-x 4 4 or C-x 5 5?
>> 
>> Indeed.  So I pushed a better patch that handles both
>> down-mouse-1 and mouse-1 events.  `dired-mouse-find-file'
>> is on mouse-1/2, so it's not ignored anymore:
>> 
>> diff --git a/lisp/window.el b/lisp/window.el
>> index af7680e4486..068b4d61f79 100644
>> --- a/lisp/window.el
>> +++ b/lisp/window.el
>> @@ -9672,7 +9679,10 @@ display-buffer-override-next-command
>>  		     (> (minibuffer-depth) minibuffer-depth)
>>  		     ;; But don't remove immediately after
>>  		     ;; adding the hook by the same command below.
>> -		     (eq this-command command))
>> +		     (eq this-command command)
>> +                     ;; Don't exit on mouse down event
>> +                     ;; in anticipation of mouse release event.
>> +                     (memq 'down (event-modifiers last-input-event)))
>>                (funcall exitfun))))
>>      ;; Call post-function after the next command finishes (bug#49057).
>>      (add-hook 'post-command-hook postfun)
>
> Thanks, but how general is this fix?

This fix is general unlike the first version that hard-coded mouse-drag-region.

> What if some bindings change the command invoked as mouse-drag-region
> in this case, and we have a different command "interfering"?

Both commands (bound to down-mouse-1 and mouse-1) should be handled here,
regardless of whether it's mouse-drag-region or anything else.

> For that matter, could you please explain how exactly did
> mouse-drag-region "get in the way" of the "C-x 4 4" feature?  Because
> I still don't understand the root cause of the problem, and the fix
> you installed doesn't explain that to me.  I therefore cannot
> understand the implications of the fix, and IMO we should continue
> discussing this until we have a complete understanding of both the
> problem and its fix.

Looking at 'C-h l' (view-lossage) explains everything:

 C-x 5 5          ;; other-frame-prefix
 <down-mouse-1>   ;; mouse-drag-region
 <mouse-1>        ;; dired-mouse-find-file

Now both commands for <down-mouse-1> and <mouse-1> are handled.




This bug report was last modified 28 days ago.

Previous Next


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