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
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>
To reply to this bug, email your comments to 78945 AT debbugs.gnu.org.
There is no need to reopen the bug first.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Wed, 02 Jul 2025 19:13:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Alcor <alcor <at> tilde.club>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Wed, 02 Jul 2025 19:13:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Steps to reproduce:
1. Start a fresh emacs -Q process
2. Open some directory in dired via e.g. C-x C-f /tmp RET
3. Rebind <mouse-2> to dired-find-file via (define-key dired-mode-map
(kbd "<mouse-2>") #'dired-find-file)
4a. Try C-x 4 4 and click on a filename
OR
4b. Try C-x 5 5 and click on a filename
Expected behavior:
The file is opened in a new window (if 4a i.e. C-x 4 4) or a new frame
(if 4b aka C-x 5 5).
Observed behavior:
C-x 4 4 or C-x 5 5 are ignored. `dired-find-file' always opens the
clicked file in the same window.
In GNU Emacs 30.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.41,
cairo version 1.18.0) of 2025-06-29 built on lcy02-amd64-115
Repository revision: 3c103e7c295c18cc75553fc09b3d603dab7b6703
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12302006
System Description: Ubuntu 24.04.2 LTS
Configured using:
'configure --prefix=/snap/emacs/current/usr --with-x-toolkit=gtk3
--without-xaw3d --with-modules --with-cairo
--with-native-compilation=aot --without-pgtk --with-xinput2
--with-tree-sitter 'CFLAGS=-isystem
/build/emacs/parts/emacs/install/usr/include -isystem
/build/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu -isystem
/build/emacs/stage/usr/include -O2' 'CPPFLAGS=-isystem
/build/emacs/parts/emacs/install/usr/include -isystem
/build/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu -isystem
/build/emacs/stage/usr/include'
'LDFLAGS=-L/build/emacs/parts/emacs/install/lib
-L/build/emacs/parts/emacs/install/usr/lib
-L/build/emacs/parts/emacs/install/lib/x86_64-linux-gnu
-L/build/emacs/parts/emacs/install/usr/lib/x86_64-linux-gnu
-L/build/emacs/stage/usr/lib''
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP
NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB
Important settings:
value of $LANG: de_DE.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Text
Minor modes in effect:
whitespace-mode: t
display-line-numbers-mode: t
goto-address-mode: t
which-key-mode: t
winner-mode: t
windmove-mode: t
recentf-mode: t
global-auto-revert-mode: t
fido-vertical-mode: t
icomplete-vertical-mode: t
icomplete-mode: t
fido-mode: t
desktop-save-mode: t
minibuffer-depth-indicate-mode: t
delete-selection-mode: t
repeat-mode: t
override-global-mode: t
tooltip-mode: t
global-eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
minibuffer-regexp-mode: t
column-number-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime
smime gnutls dig gnus-sum shr pixel-fill kinsoku url-file svg dom
gnus-group gnus-undo gnus-start gnus-dbus dbus xml gnus-cloud nnimap
nnmail mail-source utf7 nnoo parse-time iso8601 gnus-spec gnus-int
gnus-range gnus-win emacsbug message yank-media puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums disp-table whitespace
display-line-numbers goto-addr thingatpt gnus nnheader gnus-util
text-property-search time-date mail-utils range mm-util mail-prsvr
doom-themes-ext-org doom-themes-ext-visual-bell face-remap
doom-nord-theme pcase doom-themes doom-themes-base which-key finder-inf
use-package-ensure winner ring windmove recentf tree-widget autorevert
filenotify icomplete desktop frameset mb-depth delsel repeat edmacro
kmacro use-package-bind-key bind-key easy-mmode cus-edit pp cus-load
wid-edit use-package-core site-start comp comp-cstr cl-extra help-mode
comp-common warnings rx doom-themes-autoloads erc-irc-format-autoloads
markdown-mode-autoloads rainbow-delimiters-autoloads package browse-url
url url-proxy url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs icons password-cache json
subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib
rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd touch-screen tool-bar dnd fontset image regexp-opt
fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode
register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting cairo gtk x-toolkit xinput2 x multi-tty move-toolbar
make-network-process native-compile emacs)
Memory information:
((conses 16 495938 18679) (symbols 48 24742 0)
(strings 32 134936 4843) (string-bytes 1 3328789) (vectors 16 36024)
(vector-slots 8 432373 11360) (floats 8 525 7563)
(intervals 56 459 0) (buffers 992 10))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Thu, 03 Jul 2025 04:47:03 GMT)
Full text and
rfc822 format available.
Message #8 received at 78945 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 02 Jul 2025 21:11:32 +0200
> From: Alcor via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
>
> Steps to reproduce:
>
> 1. Start a fresh emacs -Q process
> 2. Open some directory in dired via e.g. C-x C-f /tmp RET
> 3. Rebind <mouse-2> to dired-find-file via (define-key dired-mode-map
> (kbd "<mouse-2>") #'dired-find-file)
> 4a. Try C-x 4 4 and click on a filename
> OR
> 4b. Try C-x 5 5 and click on a filename
>
> Expected behavior:
>
> The file is opened in a new window (if 4a i.e. C-x 4 4) or a new frame
> (if 4b aka C-x 5 5).
>
> Observed behavior:
>
> C-x 4 4 or C-x 5 5 are ignored. `dired-find-file' always opens the
> clicked file in the same window.
I cannot reproduce this. I tried both in Emacs 30.1 and in the
current pretest of Emacs 30.2, and I get the expected behavior in both
cases. I'm not on Ubuntu, but I doubt if this could be specific to
Ubuntu or to X.
Can anyone else reproduce this?
P.S. Your Subject says dired-mouse-find-file, whereas the recipe uses
dired-find-file. I tried both, and I get the expected behavior with
both.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Thu, 03 Jul 2025 06:14:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 78945 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> P.S. Your Subject says dired-mouse-find-file, whereas the recipe uses
> dired-find-file. I tried both, and I get the expected behavior with
> both.
I apologize, there is one important distinction in the bug report I
should have made: I meant "single-click" by "click", i.e. <mouse-1> in
Emacs jargon.
Clicking <mouse-2> directly works correctly and does exhibit the
expected behavior. The issue here is that C-x 4 4 and C-x 5 5 do not
work when the <mouse-2> is translated from <mouse-1>.
As for `dired-mouse-find-file' vs. `dired-find-file' - I have meant to
write `dired-mouse-find-file' in the original message, but the behavior
should be reproducible with both.
For completeness, the corrected reproducer looks like this:
1. Start a fresh emacs -Q process
2. Open some directory in dired via e.g. C-x C-f /tmp RET
3. Rebind <mouse-2> to dired-mouse-find-file via (define-key dired-mode-map
(kbd "<mouse-2>") #'dired-mouse-find-file)
4a. Try C-x 4 4 and single-click (<mouse-1>) on a filename
OR
4b. Try C-x 5 5 and single-click (<mouse-1>) on a filename
I'm not sure how I should describe/retitle the issue - maybe "C-x 4 4
and C-x 5 5 do not work with `dired-mouse-find-file' using a translated
keybind"?
Also, I'd like to mention that this behavior is not just limited to GUI
Emacs. Trying the above with `emacs -nw' with M-x xterm-mouse-mode
yields the same results.
Cheers,
-A.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Thu, 03 Jul 2025 06:37:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 78945 <at> debbugs.gnu.org (full text, mbox):
> For completeness, the corrected reproducer looks like this:
>
> 1. Start a fresh emacs -Q process
> 2. Open some directory in dired via e.g. C-x C-f /tmp RET
> 3. Rebind <mouse-2> to dired-mouse-find-file via (define-key dired-mode-map
> (kbd "<mouse-2>") #'dired-mouse-find-file)
> 4a. Try C-x 4 4 and single-click (<mouse-1>) on a filename
> OR
> 4b. Try C-x 5 5 and single-click (<mouse-1>) on a filename
Thanks for the corrected reproducer. The 'C-h l' (view-lossage)
shows that 'mouse-drag-region' gets in the way:
C-x 5 5 ;; other-frame-prefix
<down-mouse-1> ;; mouse-drag-region
<mouse-1> ;; dired-mouse-find-file
C-h l ;; view-lossage
If there are no better ideas, maybe it should be ignored explicitly:
diff --git a/lisp/window.el b/lisp/window.el
index af7680e4486..3e245741caa 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -9672,7 +9679,8 @@ 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)
+ (memq this-command '(mouse-drag-region)))
(funcall exitfun))))
;; Call post-function after the next command finishes (bug#49057).
(add-hook 'post-command-hook postfun)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Thu, 03 Jul 2025 07:31:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 78945 <at> debbugs.gnu.org (full text, mbox):
> From: Alcor <alcor <at> tilde.club>
> Cc: 78945 <at> debbugs.gnu.org
> Date: Thu, 03 Jul 2025 08:13:15 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > P.S. Your Subject says dired-mouse-find-file, whereas the recipe uses
> > dired-find-file. I tried both, and I get the expected behavior with
> > both.
>
> I apologize, there is one important distinction in the bug report I
> should have made: I meant "single-click" by "click", i.e. <mouse-1> in
> Emacs jargon.
>
> Clicking <mouse-2> directly works correctly and does exhibit the
> expected behavior. The issue here is that C-x 4 4 and C-x 5 5 do not
> work when the <mouse-2> is translated from <mouse-1>.
>
> As for `dired-mouse-find-file' vs. `dired-find-file' - I have meant to
> write `dired-mouse-find-file' in the original message, but the behavior
> should be reproducible with both.
>
> For completeness, the corrected reproducer looks like this:
>
> 1. Start a fresh emacs -Q process
> 2. Open some directory in dired via e.g. C-x C-f /tmp RET
> 3. Rebind <mouse-2> to dired-mouse-find-file via (define-key dired-mode-map
> (kbd "<mouse-2>") #'dired-mouse-find-file)
> 4a. Try C-x 4 4 and single-click (<mouse-1>) on a filename
> OR
> 4b. Try C-x 5 5 and single-click (<mouse-1>) on a filename
Thanks, I do see this, and I added the relevant people to this
discussion, in the hope that they will explain why we lose the effect
of "C-x 4 4" while redirecting mouse-1 to mouse-2.
> I'm not sure how I should describe/retitle the issue - maybe "C-x 4 4
> and C-x 5 5 do not work with `dired-mouse-find-file' using a translated
> keybind"?
>
> Also, I'd like to mention that this behavior is not just limited to GUI
> Emacs. Trying the above with `emacs -nw' with M-x xterm-mouse-mode
> yields the same results.
>
> Cheers,
> -A.
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Thu, 03 Jul 2025 10:10:03 GMT)
Full text and
rfc822 format available.
Message #20 received at 78945 <at> debbugs.gnu.org (full text, mbox):
> Thanks, I do see this, and I added the relevant people to this
> discussion, in the hope that they will explain why we lose the effect
> of "C-x 4 4" while redirecting mouse-1 to mouse-2.
I cannot contribute much. Here rebinding mouse-2 is not necessary to
show the faulty behavior and Juri's patch fixes the behavior for mouse-1
and also for mouse-2 if it is rebound. And the standard behavior here
is to always show a buffer for the file in a new window, that is C-x 4 4
would not be needed anyway.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Thu, 03 Jul 2025 16:56:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 78945 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> Thanks for the corrected reproducer. The 'C-h l' (view-lossage)
> shows that 'mouse-drag-region' gets in the way:
>
> C-x 5 5 ;; other-frame-prefix
> <down-mouse-1> ;; mouse-drag-region
> <mouse-1> ;; dired-mouse-find-file
> C-h l ;; view-lossage
>
> If there are no better ideas, maybe it should be ignored explicitly:
>
> diff --git a/lisp/window.el b/lisp/window.el
> index af7680e4486..3e245741caa 100644
> --- a/lisp/window.el
> +++ b/lisp/window.el
> @@ -9672,7 +9679,8 @@ 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)
> + (memq this-command '(mouse-drag-region)))
> (funcall exitfun))))
> ;; Call post-function after the next command finishes (bug#49057).
> (add-hook 'post-command-hook postfun)
Thanks for the above patch, I can also confirm this fixes the issue when
applied on 30.1.
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?
Cheers,
-A.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Thu, 03 Jul 2025 17:37:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 78945 <at> debbugs.gnu.org (full text, mbox):
close 78945 31.0.50
thanks
> 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)
bug marked as fixed in version 31.0.50, send any further explanations to
78945 <at> debbugs.gnu.org and Alcor <alcor <at> tilde.club>
Request was from
Juri Linkov <juri <at> linkov.net>
to
control <at> debbugs.gnu.org.
(Thu, 03 Jul 2025 17:37:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Thu, 03 Jul 2025 19:15:03 GMT)
Full text and
rfc822 format available.
Message #31 received at 78945 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> 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:
Thanks Juri & Eli.
Since the original issue was filed against 30.1, and the patch seems
minimal enough - would it be possible to ask for a backport to the
emacs-30 branch so this fix may make it into 30.2?
Cheers,
-A
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Fri, 04 Jul 2025 06:29:03 GMT)
Full text and
rfc822 format available.
Message #34 received at 78945 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: 78945 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> Date: Thu, 03 Jul 2025 20:34:42 +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? What if some bindings change the
command invoked as mouse-drag-region in this case, and we have a
different command "interfering"?
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Fri, 04 Jul 2025 06:45:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 78945 <at> debbugs.gnu.org (full text, mbox):
>> > 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Fri, 04 Jul 2025 06:58:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 78945 <at> debbugs.gnu.org (full text, mbox):
> From: Alcor <alcor <at> tilde.club>
> Cc: 78945 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> Date: Thu, 03 Jul 2025 21:14:51 +0200
>
> Juri Linkov <juri <at> linkov.net> writes:
>
> > 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:
>
> Thanks Juri & Eli.
>
> Since the original issue was filed against 30.1, and the patch seems
> minimal enough - would it be possible to ask for a backport to the
> emacs-30 branch so this fix may make it into 30.2?
In general, no, because this fix is somewhat ad-hoc, and therefore
could have unintended consequences; that is inappropriate on the
release branch at this time. But please wait until the discussion of
this bug and its fix is completed, because only then we will have a
complete picture about the root cause and the expected effects of the
solution we will install (which is not necessarily what was already
installed, for the reasons I tried to explain in my previous message).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Fri, 04 Jul 2025 07:48:03 GMT)
Full text and
rfc822 format available.
Message #43 received at 78945 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, alcor <at> tilde.club,
> 78945 <at> debbugs.gnu.org
> Date: Fri, 04 Jul 2025 09:42:07 +0300
>
> > 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
Sorry, it doesn't, not to me, probably because I don't understand well
enough what "C-x 4 4" does and how. So please talk me through the
code which implements "C-x 4 4" and explain how down-mouse-1 in the
middle defeated it. Without that, I cannot understand the fix and its
generality.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Fri, 04 Jul 2025 13:57:02 GMT)
Full text and
rfc822 format available.
Message #46 received at 78945 <at> debbugs.gnu.org (full text, mbox):
> 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
BTW, `help--read-key-sequence` faces the same problem (and tries to
additionally handle the same issue for double-clicks).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Mon, 07 Jul 2025 06:46:01 GMT)
Full text and
rfc822 format available.
Message #49 received at submit <at> debbugs.gnu.org (full text, mbox):
>> 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
>
> BTW, `help--read-key-sequence` faces the same problem (and tries to
> additionally handle the same issue for double-clicks).
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
`describe-key` uses
(and (not (memq mouse-1-click-follows-link '(nil double)))
(> (length raw) 0)
(eq (car-safe (aref raw 0)) 'mouse-1)
But I'm afraid that not exiting on <mouse-1> in
`display-buffer-override-next-command` would be too error-prone.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Mon, 07 Jul 2025 06:46:02 GMT)
Full text and
rfc822 format available.
Message #52 received at 78945 <at> debbugs.gnu.org (full text, mbox):
>> > 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
>
> Sorry, it doesn't, not to me, probably because I don't understand well
> enough what "C-x 4 4" does and how. So please talk me through the
> code which implements "C-x 4 4" and explain how down-mouse-1 in the
> middle defeated it. Without that, I cannot understand the fix and its
> generality.
The docstring of "C-x 4 4" says:
Display the buffer of the next command in a new window.
Clicking the mouse button runs two commands, so both should be handled here.
Or do you think this special case should be mentioned in the docstring?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Mon, 07 Jul 2025 06:46:04 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Mon, 07 Jul 2025 13:59:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 78945 <at> debbugs.gnu.org (full text, mbox):
> 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?
> `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.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Mon, 07 Jul 2025 14:06:02 GMT)
Full text and
rfc822 format available.
Message #61 received at 78945 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: monnier <at> iro.umontreal.ca, alcor <at> tilde.club, 78945 <at> debbugs.gnu.org
> Date: Mon, 07 Jul 2025 09:34:17 +0300
>
> >> 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
> >
> > Sorry, it doesn't, not to me, probably because I don't understand well
> > enough what "C-x 4 4" does and how. So please talk me through the
> > code which implements "C-x 4 4" and explain how down-mouse-1 in the
> > middle defeated it. Without that, I cannot understand the fix and its
> > generality.
>
> The docstring of "C-x 4 4" says:
>
> Display the buffer of the next command in a new window.
>
> Clicking the mouse button runs two commands, so both should be handled here.
> Or do you think this special case should be mentioned in the docstring?
We should probably document it once we agree and understand the full
effect of the change.
Right now, I understand that:
. "C-x 4 4" etc. can affect more than just one next command -- as
long as the commands have the 'down' modifier, we will keep the
override in effect -- is this expected or TRT?
. If some command is bound to mouse-down event, it might not be the
only command affected by "C-x 4 4" -- do we want that?
. What about commands bound to double clicks and triple clicks?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Mon, 07 Jul 2025 17:14:02 GMT)
Full text and
rfc822 format available.
Message #64 received at 78945 <at> debbugs.gnu.org (full text, mbox):
>> >> 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
>> >
>> > Sorry, it doesn't, not to me, probably because I don't understand well
>> > enough what "C-x 4 4" does and how. So please talk me through the
>> > code which implements "C-x 4 4" and explain how down-mouse-1 in the
>> > middle defeated it. Without that, I cannot understand the fix and its
>> > generality.
>>
>> The docstring of "C-x 4 4" says:
>>
>> Display the buffer of the next command in a new window.
>>
>> Clicking the mouse button runs two commands, so both should be handled here.
>> Or do you think this special case should be mentioned in the docstring?
>
> We should probably document it once we agree and understand the full
> effect of the change.
>
> Right now, I understand that:
>
> . "C-x 4 4" etc. can affect more than just one next command -- as
> long as the commands have the 'down' modifier, we will keep the
> override in effect -- is this expected or TRT?
This is the right thing since it fixes the reported problem.
> . If some command is bound to mouse-down event, it might not be the
> only command affected by "C-x 4 4" -- do we want that?
Yes, we need to handle mouse-down and mouse-up commands.
> . What about commands bound to double clicks and triple clicks?
This is doable.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Mon, 07 Jul 2025 17:14:03 GMT)
Full text and
rfc822 format available.
Message #67 received at 78945 <at> debbugs.gnu.org (full text, mbox):
>> 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)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Mon, 07 Jul 2025 19:21:02 GMT)
Full text and
rfc822 format available.
Message #70 received at 78945 <at> debbugs.gnu.org (full text, mbox):
>> 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)
LGTM.
`help--read-key-sequence` combines it with a time-limit because we don't
want `C-h k` to sit there indefinitely, but it doesn't seem needed here,
indeed, since in most cases the override will have been
disabled/consumed by an intervening `display-buffer` anyway.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Wed, 09 Jul 2025 06:53:02 GMT)
Full text and
rfc822 format available.
Message #73 received at 78945 <at> debbugs.gnu.org (full text, mbox):
>> @@ -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)
>
> LGTM.
>
> `help--read-key-sequence` combines it with a time-limit because we don't
> want `C-h k` to sit there indefinitely, but it doesn't seem needed here,
> indeed, since in most cases the override will have been
> disabled/consumed by an intervening `display-buffer` anyway.
Now pushed with docstring updates that describe this behavior.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Wed, 09 Jul 2025 10:59:02 GMT)
Full text and
rfc822 format available.
Message #76 received at 78945 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: monnier <at> iro.umontreal.ca, alcor <at> tilde.club, 78945 <at> debbugs.gnu.org
> Date: Mon, 07 Jul 2025 19:57:29 +0300
>
> >> >> 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
> >> >
> >> > Sorry, it doesn't, not to me, probably because I don't understand well
> >> > enough what "C-x 4 4" does and how. So please talk me through the
> >> > code which implements "C-x 4 4" and explain how down-mouse-1 in the
> >> > middle defeated it. Without that, I cannot understand the fix and its
> >> > generality.
> >>
> >> The docstring of "C-x 4 4" says:
> >>
> >> Display the buffer of the next command in a new window.
> >>
> >> Clicking the mouse button runs two commands, so both should be handled here.
> >> Or do you think this special case should be mentioned in the docstring?
> >
> > We should probably document it once we agree and understand the full
> > effect of the change.
> >
> > Right now, I understand that:
> >
> > . "C-x 4 4" etc. can affect more than just one next command -- as
> > long as the commands have the 'down' modifier, we will keep the
> > override in effect -- is this expected or TRT?
>
> This is the right thing since it fixes the reported problem.
Then it should be documented. Right now, we are talking about "the
next command", singular.
> > . If some command is bound to mouse-down event, it might not be the
> > only command affected by "C-x 4 4" -- do we want that?
>
> Yes, we need to handle mouse-down and mouse-up commands.
Again, should be documented.
> > . What about commands bound to double clicks and triple clicks?
>
> This is doable.
I think we should do it, then, to avoid subtle inconsistencies (and
future bugs).
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Wed, 09 Jul 2025 11:15:03 GMT)
Full text and
rfc822 format available.
Message #79 received at 78945 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 78945 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, alcor <at> tilde.club
> Date: Mon, 07 Jul 2025 15:20:42 -0400
>
> >> 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)
>
> LGTM.
Does this mean any mouse-click command will cause the next command
also be affected by "C-x 4 4" and friends?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Wed, 09 Jul 2025 21:45:04 GMT)
Full text and
rfc822 format available.
Message #82 received at 78945 <at> debbugs.gnu.org (full text, mbox):
>> > @@ -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)
>>
>> LGTM.
>
> Does this mean any mouse-click command will cause the next command
> also be affected by "C-x 4 4" and friends?
Sometimes, yes. But only when the mouse-click command did not itself
use `display-buffer`.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Thu, 10 Jul 2025 06:11:02 GMT)
Full text and
rfc822 format available.
Message #85 received at 78945 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: juri <at> linkov.net, 78945 <at> debbugs.gnu.org, alcor <at> tilde.club
> Date: Wed, 09 Jul 2025 17:44:36 -0400
>
> >> > @@ -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)
> >>
> >> LGTM.
> >
> > Does this mean any mouse-click command will cause the next command
> > also be affected by "C-x 4 4" and friends?
>
> Sometimes, yes. But only when the mouse-click command did not itself
> use `display-buffer`.
I wonder how we could document this in user-facing terms, so that
users would know what to expect from using these prefixes. Any ideas
or suggestions?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Thu, 10 Jul 2025 06:59:01 GMT)
Full text and
rfc822 format available.
Message #88 received at 78945 <at> debbugs.gnu.org (full text, mbox):
>> > Does this mean any mouse-click command will cause the next command
>> > also be affected by "C-x 4 4" and friends?
>>
>> Sometimes, yes. But only when the mouse-click command did not itself
>> use `display-buffer`.
>
> I wonder how we could document this in user-facing terms, so that
> users would know what to expect from using these prefixes. Any ideas
> or suggestions?
I already documented this.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Thu, 10 Jul 2025 07:30:02 GMT)
Full text and
rfc822 format available.
Message #91 received at 78945 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 78945 <at> debbugs.gnu.org,
> alcor <at> tilde.club
> Date: Thu, 10 Jul 2025 09:58:08 +0300
>
> >> > Does this mean any mouse-click command will cause the next command
> >> > also be affected by "C-x 4 4" and friends?
> >>
> >> Sometimes, yes. But only when the mouse-click command did not itself
> >> use `display-buffer`.
> >
> > I wonder how we could document this in user-facing terms, so that
> > users would know what to expect from using these prefixes. Any ideas
> > or suggestions?
>
> I already documented this.
I guess you mean the below?
In case of multiple consecutive mouse events such as <down-mouse-1>,
a mouse release event <mouse-1>, <double-mouse-1>, <triple-mouse-1>
all bound commands are handled until one of them displays a buffer.
If so, I've seen this, thanks. But (a) it is IMO too terse to make
the effect clear, and (b) the manuals don't document these prefixes at
all AFAICS (I saw nothing in NEWS, either).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Thu, 10 Jul 2025 18:56:04 GMT)
Full text and
rfc822 format available.
Message #94 received at 78945 <at> debbugs.gnu.org (full text, mbox):
> I guess you mean the below?
>
> In case of multiple consecutive mouse events such as <down-mouse-1>,
> a mouse release event <mouse-1>, <double-mouse-1>, <triple-mouse-1>
> all bound commands are handled until one of them displays a buffer.
>
> If so, I've seen this, thanks. But (a) it is IMO too terse to make
> the effect clear, and (b) the manuals don't document these prefixes at
> all AFAICS (I saw nothing in NEWS, either).
In what Info nodes they could be documented?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Fri, 11 Jul 2025 06:27:02 GMT)
Full text and
rfc822 format available.
Message #97 received at 78945 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: monnier <at> iro.umontreal.ca, 78945 <at> debbugs.gnu.org, alcor <at> tilde.club
> Date: Thu, 10 Jul 2025 21:54:59 +0300
>
> > I guess you mean the below?
> >
> > In case of multiple consecutive mouse events such as <down-mouse-1>,
> > a mouse release event <mouse-1>, <double-mouse-1>, <triple-mouse-1>
> > all bound commands are handled until one of them displays a buffer.
> >
> > If so, I've seen this, thanks. But (a) it is IMO too terse to make
> > the effect clear, and (b) the manuals don't document these prefixes at
> > all AFAICS (I saw nothing in NEWS, either).
>
> In what Info nodes they could be documented?
Actually, I see that I was mistaken: the user manual does describe
"C-x 4 4" and "C-x 5 5", just without an index entry; I've now fixed
that. However, the subtle effect on several mouse-bound commands
still needs to be described there.
As for the ELisp manual, I think the right place is in the "Prefix
Keys" node. What I think we should describe there is that this prefix
command works via display-buffer-alist, and also how the multiple
mouse clicks are handled for this purpose.
I also have a question: if I type "C-x 4 4" before a mouse-bound
command that shows no buffer, does it mean that the next command
(which could be arbitrary and unrelated) will be affected by the
prefix? If so, we should mention this subtlety in the ELisp manual.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78945; Package
emacs.
(Fri, 11 Jul 2025 14:19:02 GMT)
Full text and
rfc822 format available.
Message #100 received at 78945 <at> debbugs.gnu.org (full text, mbox):
> I also have a question: if I type "C-x 4 4" before a mouse-bound
> command that shows no buffer, does it mean that the next command
> (which could be arbitrary and unrelated) will be affected by the
> prefix?
Yes. This is the undesirable consequence of the patch. For a single
click, it is hard to fix this while still allowing `C-x 4 4` to apply to
double-click commands since after the first click we don't know yet if
another click is coming.
We could try and add some hack with a `pre-command-hook` such that after
a mouse event we disable the `C-x 4 4` if the next event is not among
a specific subset of events (e.g. after a down event we keep the `C-x
4 4` alive but only if the next event is the corresponding up event).
I'm not sure it's worth the trouble: most commands show no buffer, so in
most cases the arbitrary/unrelated next command will not be affected by
the lingering prefix anyway.
Stefan
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.