I've been finding - in last 12 months - that sometimes when I do M-x and type something the cursor has moved to the main window in that frame, and the desired command ends up in that window if it is a 'normal' buffer or does more drastic things if (for example) in dired. from Ch l in one of these cases <escape> <select-window> x ;; execute-extended-command ;; handle-select-window g ;; revert-buffer n ;; dired-next-line u ;; dired-unmark s ;; dired-sort-toggle-or-edit you'll see that my intention of typing M-x gnus has been subverted and the commands are happening in a dired buffer! I have (setq mouse-autoselect-window 1) but I don't think I'm pausing long enough (and it doesn't see to kick in anyway from a minibuffer) that handle-select-window is clearly the problem but not sure where it is coming from, and it is happening very rarely so I'd prefer not to set a break there. (plasma desktop environment - in case that's relevant) Robert In GNU Emacs 28.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, cairo version 1.16.0) of 2021-04-15 built on poulenc Repository revision: 3b84f8f47c1e2ad2842e3f5ce38823d3083ad12a Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12009000 System Description: Ubuntu 20.10 Configured using: 'configure --with-xpm=ifavailable' Configured features: CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LCMS2 LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3 ZLIB Important settings: value of $LANG: en_GB.UTF-8 value of $XMODIFIERS: @im=ibus locale-coding-system: utf-8-unix Major mode: Help Minor modes in effect: which-function-mode: t shell-dirtrack-mode: t global-hi-lock-mode: t hi-lock-mode: t desktop-save-mode: t recentf-mode: t show-paren-mode: t tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t buffer-read-only: t line-number-mode: t transient-mark-mode: t Load-path shadows: /home/robert/elisp/dired-async hides /home/robert/.emacs.d/elpa/async-20191030.2138/dired-async /home/robert/elisp/async hides /home/robert/.emacs.d/elpa/async-20191030.2138/async Features: (shadow emacsbug vm-digest cal-move vm-mark gnus-fun imgur log-view pcvs-util shortdoc help-fns radix-tree smerge-mode diff dabbrev tabify man url-cache pp gnutls smtpmail shr-color find-dired grep canlock bbdb-message footnote rx sort smiley gnus-cite flow-fill mm-archive mail-extr gnus-bcklg gnus-async qp gnus-ml disp-table gnus-topic cursor-sensor nndraft nnmh nnfolder gnus-agent gnus-srvr gnus-score nnvirtual gnus-msg gnus-cache bbdb-gnus network-stream nntp sendmail bbdb-vm bbdb-mua bbdb-com crm bbdb bbdb-site timezone vm-pine vm-edit vm-rfaddons vm-reply vm-imap vm-save vm-virtual vm-summary-faces vm-delete vm-pop vm-undo vm-sort vm-thread vm-mime vm-toolbar vm-menu tapestry vm-window vm-folder vm-crypto vm-summary vm-mouse vm-page vm-motion vm-minibuf vm-message vm-misc vm-macro vm-autoloads vm-vars vm-version vm misearch multi-isearch dcl-mode tempo tramp-archive tramp-gvfs tramp-cache zeroconf perl-mode score-mode conf-mode view python tramp-sh tramp tramp-loaddefs trampver tramp-integration files-x tramp-compat ls-lisp rng-xsd xsd-regexp rng-cmpct rng-nxml rng-valid rng-loc rng-uri rng-parse nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns nxml-mode nxml-outln nxml-rap nxml-util nxml-enc xmltok arc-mode archive-mode vc-bzr eimp vc-dir ewoc vc mule-util markdown-mode make-mode org-element avl-tree generator ol-eww ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect gnus-search eieio-opt speedbar ezimage dframe gnus-art mm-uu mml2015 mm-view mml-smime smime dig gnus-sum gnus-group gnus-undo gnus-start gnus-dbus dbus gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range message rfc822 mml mml-sec epa derived epg epg-config mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader gnus-win ol-docview doc-view jka-compr image-mode exif ol-bibtex bibtex ol-bbdb ol-w3m org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-footnote org-src ob-comint org-pcomplete org-list org-faces org-entities noutline outline org-version ob-emacs-lisp ob-core ob-eval org-table ol org-keys org-compat org-macs org-loaddefs format-spec find-func add-log which-func vc-cvs flyspell ispell tex-mode compile shell pcomplete comint ansi-color ring cl-extra help-mode mhtml-mode css-mode eww xdg url-queue thingatpt shr kinsoku svg mm-url gnus nnheader gnus-util rmail rmail-loaddefs text-property-search mail-utils color js imenu cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs sgml-mode facemenu dom vc-git diff-mode easy-mmode vc-dispatcher bug-reference reveal sh-script smie executable dired-aux dired-x dired dired-loaddefs twittering-mode advice identica-mode url-http url-auth mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr url-gw nsm rmc puny longlines parse-time iso8601 time-date xml cl cal-china lunar solar cal-dst cal-bahai cal-islam cal-hebrew holidays hol-loaddefs diary-lib diary-loaddefs cal-menu calendar cal-loaddefs server tbemail org-install hi-lock edmacro kmacro desktop frameset recentf tree-widget wid-edit paren bbdb-loaddefs finder-inf info package browse-url url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json subr-x map url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-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 cl-generic 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 charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 2462049 258618) (symbols 48 109522 26) (strings 32 717647 33266) (string-bytes 1 19958259) (vectors 16 292703) (vector-slots 8 4204652 233649) (floats 8 1278 963) (intervals 56 245326 77) (buffers 992 703))
>
> I've been finding - in last 12 months - that sometimes when I do M-x and
> type something the cursor has moved to the main window in that frame,
> and the desired command ends up in that window if it is a 'normal'
> buffer or does more drastic things if (for example) in dired.
>
> from Ch l in one of these cases
> <escape> <select-window> x ;; execute-extended-command
> ;; handle-select-window
> g ;; revert-buffer
> n ;; dired-next-line
> u ;; dired-unmark
> s ;; dired-sort-toggle-or-edit
>
> you'll see that my intention of typing M-x gnus has been subverted and
> the commands are happening in a dired buffer!
>
> I have (setq mouse-autoselect-window 1) but I don't think I'm pausing
> long enough (and it doesn't see to kick in anyway from a minibuffer)
> that handle-select-window is clearly the problem but not sure where it
> is coming from, and it is happening very rarely so I'd prefer not to set
> a break there.
>
Thanks for your bug report. I could not reproduce what you describe alas;
could you perhaps try to create a recipe, starting with emacs -Q, with
which the bug you experience is triggered?
Gregory Heytings writes: > > > > > I've been finding - in last 12 months - that sometimes when I do M-x and > > type something the cursor has moved to the main window in that frame, > > and the desired command ends up in that window if it is a 'normal' > > buffer or does more drastic things if (for example) in dired. > > > > from Ch l in one of these cases > > <escape> <select-window> x ;; execute-extended-command > > ;; handle-select-window > > g ;; revert-buffer > > n ;; dired-next-line > > u ;; dired-unmark > > s ;; dired-sort-toggle-or-edit > > > > you'll see that my intention of typing M-x gnus has been subverted and > > the commands are happening in a dired buffer! > > > > I have (setq mouse-autoselect-window 1) but I don't think I'm pausing > > long enough (and it doesn't see to kick in anyway from a minibuffer) > > that handle-select-window is clearly the problem but not sure where it > > is coming from, and it is happening very rarely so I'd prefer not to set > > a break there. > > > > Thanks for your bug report. I could not reproduce what you describe alas; > could you perhaps try to create a recipe, starting with emacs -Q, with > which the bug you experience is triggered? > I will attempt to - however I'm only seeing this behaviour once a week or so, so difficult to replicate. My impression is that it used to happen more frequently when I was running a build from git made spring 2020, it's now less frequent but still occurring. I shall steer clear of functions starting with the characters dxyes - that way lies data loss with this bug and a dired buffer ;) Robert -- Robert Marshall twitter: @rajm
>
> I will attempt to - however I'm only seeing this behaviour once a week
> or so, so difficult to replicate. My impression is that it used to
> happen more frequently when I was running a build from git made spring
> 2020, it's now less frequent but still occurring.
>
I think I managed to reproduce the issue you see:
emacs -Q
M-: (setq mouse-autoselect-window t)
C-x 2
move mouse to the upper window
ESC
move mouse to the lower window
xgnus
"x" is interpreted correctly and becomes M-x, but "gnus" is typed in the
buffer in the lower window.
Could you confirm that this correctly reproduces what you see?
Gregory Heytings writes: > > > > > I will attempt to - however I'm only seeing this behaviour once a week > > or so, so difficult to replicate. My impression is that it used to > > happen more frequently when I was running a build from git made spring > > 2020, it's now less frequent but still occurring. > > > > I think I managed to reproduce the issue you see: > > emacs -Q > M-: (setq mouse-autoselect-window t) > C-x 2 > move mouse to the upper window > ESC > move mouse to the lower window > xgnus > > "x" is interpreted correctly and becomes M-x, but "gnus" is typed in the > buffer in the lower window. > > Could you confirm that this correctly reproduces what you see? > Brilliant! Yes that's precisely what I'm seeing Robert -- Robert Marshall twitter: @rajm
>> Could you confirm that this correctly reproduces what you see?
>
> Brilliant! Yes that's precisely what I'm seeing
>
Thanks for your confirmation, I'll investigate this issue.
[-- Attachment #1: Type: text/plain, Size: 188 bytes --] Patch attached. Could you please test it, and confirm that it correctly fixes the issue? Cc'ing Martin, who authored most of the handle-select-window function. The recipe is upthread. [-- Attachment #2: Type: text/x-diff, Size: 1124 bytes --] From cfc85ca0f16b194367ecfb195a237b955f81088b Mon Sep 17 00:00:00 2001 From: Gregory Heytings <gregory@heytings.org> Date: Sat, 1 May 2021 20:17:30 +0000 Subject: [PATCH] Do not switch to other window when minibuffer is selected * lisp/window.el (handle-select-window): Do not silently switch to other window when minibuffer is selected, which can happen with mouse-autoselect-window t (Bug#47969). --- lisp/window.el | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lisp/window.el b/lisp/window.el index cf5752113d..77609a794b 100644 --- a/lisp/window.el +++ b/lisp/window.el @@ -10048,6 +10048,8 @@ handle-select-window ;; already selected. (and (not (eq frame (selected-frame))) (frame-parameter frame 'no-accept-focus)) + ;; Don't switch if minibuffer window is selected. + (window-minibuffer-p) ;; Don't switch to minibuffer window unless it's active. (and (window-minibuffer-p window) (not (minibuffer-window-active-p window)))) -- 2.30.2
> Date: Sat, 01 May 2021 20:20:16 +0000
> From: Gregory Heytings <gregory@heytings.org>
> Cc: 47969@debbugs.gnu.org
>
> Patch attached. Could you please test it, and confirm that it correctly
> fixes the issue?
>
> Cc'ing Martin, who authored most of the handle-select-window function.
> The recipe is upthread.
FWIW, I think we should instead temporarily disable
mouse-autoselect-window when a minibuffer is active.
> Patch attached. Could you please test it, and confirm that it correctly fixes the issue? > > Cc'ing Martin, who authored most of the handle-select-window function. The recipe is upthread. I don't know what to say because (1) moving the mouse to the lower window does _not_ lead to typing "gnus" in that window here and (2) I'd rather consider it a bug to _not_ select the lower window in that case. Mouse window auto-selection should mimic the behavior of clicking into the lower window and clicking in that window should select it also while a minibuffer dialogue goes on. Recall that such dialogues are not modal as has been constated a number of times on this list. Note also that normally I have my minibuffer in a child frame and even there no auto-selection takes place when the minibuffer is active despite of the fact that I have set both WM focus-follows-mouse and `mouse-autoselect-window'. But I have no strong opinion so I leave it to Robert to propose what should be done here. martin
martin rudalics writes:
> > Patch attached. Could you please test it, and confirm that it correctly fixes the issue?
> >
> > Cc'ing Martin, who authored most of the handle-select-window function. The recipe is upthread.
>
> I don't know what to say because (1) moving the mouse to the lower
> window does _not_ lead to typing "gnus" in that window here and (2) I'd
> rather consider it a bug to _not_ select the lower window in that case.
Though when I've seen this bug I am not *consciously* moving the
mouse, maybe it is being accidentally jolted? Typically I was seeing
this after moving from another workspace into one containing 2 emacs
frames and immediately trying to run gnus.
>
> Mouse window auto-selection should mimic the behavior of clicking into
> the lower window and clicking in that window should select it also while
> a minibuffer dialogue goes on. Recall that such dialogues are not modal
> as has been constated a number of times on this list.
>
> Note also that normally I have my minibuffer in a child frame and even
> there no auto-selection takes place when the minibuffer is active
> despite of the fact that I have set both WM focus-follows-mouse and
> `mouse-autoselect-window'.
>
> But I have no strong opinion so I leave it to Robert to propose what
> should be done here.
>
It's a difficult call between 2 conflicting requirements. I note Eli's
comments but I've applied the patch and it fixes the issue for
me. There can be undesirable behaviour in the current behaviour. Take
this contrived example -
Create file bugProvoke.el in **empty** directory
containing
;;;--------
(setq mouse-autoselect-window t)
(defun dxyes (interactive)
(beep))
;;; end of bugProvoke.el
In that directory, emacs -Q -l bugProvoke.el
C-x d ;; dired the directory
C-x 2
ESC and move mouse into lower window
x dxyes ;; you think you're running the dxyes function?!
;;; but look at the minibuffer before you type return and delete your file
don't do this in a directory which has files you value!
Robert
>> Patch attached. Could you please test it, and confirm that it >> correctly fixes the issue? >> >> Cc'ing Martin, who authored most of the handle-select-window function. >> The recipe is upthread. > > I don't know what to say because (1) moving the mouse to the lower > window does _not_ lead to typing "gnus" in that window here and > Are you sure? I tried this recipe on GNU/Linux (27.2 and 28), macOS (27.2) and Windows (27.2), and in all cases "gnus" was typed in that window. Note that the recipe uses ESC x, not M-x. > > (2) I'd rather consider it a bug to _not_ select the lower window in > that case. > I don't know. What I do know is that mouse-autoselect-window was introduced in Emacs 22, and that in Emacs 22-25 the lower window was not selected with that recipe. That behavior changed in Emacs 26. > > Mouse window auto-selection should mimic the behavior of clicking into > the lower window and clicking in that window should select it also while > a minibuffer dialogue goes on. > This is not the case, not even in Emacs 28. If it were the case, the "ESC" would be discarded and "xgnus" would be typed in the lower window. What happens is that "x" becomes "M-x" because of the earlier "ESC", "M-x" stays in the minibuffer, and "gnus" in typed in the buffer.
Eli Zaretskii <eliz@gnu.org> writes: >> Cc'ing Martin, who authored most of the handle-select-window function. >> The recipe is upthread. > > FWIW, I think we should instead temporarily disable > mouse-autoselect-window when a minibuffer is active. I don't think that's what's happening here, exactly. If you `M-x' then moving the mouse to a different window doesn't have any effect that I can see. It's only in the test case described by Gregory that things go haywire: `ESC' + mouse move + `xfoo'. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
>> I don't know what to say because (1) moving the mouse to the lower window does _not_ lead to typing "gnus" in that window here and >> > > Are you sure? I tried this recipe on GNU/Linux (27.2 and 28), macOS (27.2) and Windows (27.2), and in all cases "gnus" was typed in that window. Note that the recipe uses ESC x, not M-x. I apparently have to move the mouse before doing the ESC. Then I can reproduce it. With an occasional select-window echo in between. >> (2) I'd rather consider it a bug to _not_ select the lower window in that case. >> > > I don't know. What I do know is that mouse-autoselect-window was introduced in Emacs 22, and that in Emacs 22-25 the lower window was not selected with that recipe. That behavior changed in Emacs 26. Do you know which commit changed it? >> Mouse window auto-selection should mimic the behavior of clicking into the lower window and clicking in that window should select it also while a minibuffer dialogue goes on. >> > > This is not the case, not even in Emacs 28. If it were the case, the "ESC" would be discarded and "xgnus" would be typed in the lower window. What happens is that "x" becomes "M-x" because of the earlier "ESC", "M-x" stays in the minibuffer, and "gnus" in typed in the buffer. Hmm.... ESC <mouse-1> is undefined. That makes the difference. In either case don't let me distract you and feel free to install any fix you consider reasonable. Thanks, martin
>> I don't know. What I do know is that mouse-autoselect-window was >> introduced in Emacs 22, and that in Emacs 22-25 the lower window was >> not selected with that recipe. That behavior changed in Emacs 26. > > Do you know which commit changed it? > I'll try to find that. > > In either case don't let me distract you and feel free to install any > fix you consider reasonable. > I don't have write access to the trunk, and my paperwork is not even finished yet :(
>>> I don't know. What I do know is that mouse-autoselect-window was
>>> introduced in Emacs 22, and that in Emacs 22-25 the lower window was
>>> not selected with that recipe. That behavior changed in Emacs 26.
>>
>> Do you know which commit changed it?
>
> I'll try to find that.
>
Okay, I bisected this, and the culprit is commit 3fdd3bb56c.
Interestingly, that commit removed the following from
handle-select-window:
;; Don't switch if we're currently in the minibuffer.
;; This tries to work around problems where the
;; minibuffer gets unselected unexpectedly, and where
;; you then have to move your mouse all the way down to
;; the minibuffer to select it.
(window-minibuffer-p)
which happens to be what my patch adds again.
> From: Lars Ingebrigtsen <larsi@gnus.org> > Cc: Gregory Heytings <gregory@heytings.org>, robert@capuchin.co.uk, > 47969@debbugs.gnu.org > Date: Mon, 03 May 2021 11:07:50 +0200 > > > FWIW, I think we should instead temporarily disable > > mouse-autoselect-window when a minibuffer is active. > > I don't think that's what's happening here, exactly. If you `M-x' then > moving the mouse to a different window doesn't have any effect that I > can see. That's because M-x isn't a prefix key, whereas ESC is. > It's only in the test case described by Gregory that things go haywire: > `ESC' + mouse move + `xfoo'. Here's a demo without ESC: M-x set-variable RET mouse-autoselect-window RET t RET C-x 2 C-x ; wait for the "C-x" prompt in the echo area ; move mouse to the other window b ; selected-window is not longer the mini-window foo ; this gets inserted into some buffer instead of the minibuffer
> Okay, I bisected this, and the culprit is commit 3fdd3bb56c. Interestingly, that commit removed the following from handle-select-window: > > ;; Don't switch if we're currently in the minibuffer. > ;; This tries to work around problems where the > ;; minibuffer gets unselected unexpectedly, and where > ;; you then have to move your mouse all the way down to > ;; the minibuffer to select it. > (window-minibuffer-p) > > which happens to be what my patch adds again. I can't give a reasonable explanation why I removed that back then, so please re-add it as soon as your paperwork is done. And many thanks for the bisection, great work as usual. martin
> From: martin rudalics <rudalics@gmx.at> > Date: Mon, 3 May 2021 14:02:13 +0200 > Cc: Robert Marshall <robert@capuchin.co.uk>, 47969@debbugs.gnu.org > > > Okay, I bisected this, and the culprit is commit 3fdd3bb56c. Interestingly, that commit removed the following from handle-select-window: > > > > ;; Don't switch if we're currently in the minibuffer. > > ;; This tries to work around problems where the > > ;; minibuffer gets unselected unexpectedly, and where > > ;; you then have to move your mouse all the way down to > > ;; the minibuffer to select it. > > (window-minibuffer-p) > > > > which happens to be what my patch adds again. > > I can't give a reasonable explanation why I removed that back then, so > please re-add it as soon as your paperwork is done. I'd actually trust your-then judgment, and instead explore the possibility of solving this as I proposed up-thread. Undoing past fixes when we don't understand the effects is bad mantra, it runs the risk of fixing one problem by reintroducing another. > And many thanks for the bisection, great work as usual. Seconded.
>> It's only in the test case described by Gregory that things go haywire:
>> `ESC' + mouse move + `xfoo'.
>
> Here's a demo without ESC:
>
> M-x set-variable RET mouse-autoselect-window RET t RET
> C-x 2
> C-x ; wait for the "C-x" prompt in the echo area
> ; move mouse to the other window
> b ; selected-window is not longer the mini-window
> foo ; this gets inserted into some buffer instead of the minibuffer
>
This recipe worked, like mine, differently in Emacs 22-25: foo was
inserted in the minibuffer.
> Date: Mon, 03 May 2021 12:15:18 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Lars Ingebrigtsen <larsi@gnus.org>, robert@capuchin.co.uk,
> 47969@debbugs.gnu.org
>
>
> > M-x set-variable RET mouse-autoselect-window RET t RET
> > C-x 2
> > C-x ; wait for the "C-x" prompt in the echo area
> > ; move mouse to the other window
> > b ; selected-window is not longer the mini-window
> > foo ; this gets inserted into some buffer instead of the minibuffer
> >
>
> This recipe worked, like mine, differently in Emacs 22-25: foo was
> inserted in the minibuffer.
Of course: it's the same problem.
> > I'd actually trust your-then judgment, and instead explore the > possibility of solving this as I proposed up-thread. Undoing past fixes > when we don't understand the effects is bad mantra, it runs the risk of > fixing one problem by reintroducing another. > If you look at 3fdd3bb56c, you'll see that it's a rather big commit (20 files changed, 2543 insertions, 454 deletions), so I tend to agree with Martin that this likely was not an intentional change. >> And many thanks for the bisection, great work as usual. > > Seconded. > Thanks :-)
> I'd actually trust your-then judgment, and instead explore the > possibility of solving this as I proposed up-thread. Undoing past > fixes when we don't understand the effects is bad mantra, it runs the > risk of fixing one problem by reintroducing another. You mean your earlier > FWIW, I think we should instead temporarily disable > mouse-autoselect-window when a minibuffer is active. as in the untested below? martin diff --git a/lisp/window.el b/lisp/window.el index f9b28fece1..b59fcd323f 100644 --- a/lisp/window.el +++ b/lisp/window.el @@ -10672,7 +10672,8 @@ mouse-autoselect-window-select (window (and frame (window-at mouse-x mouse-y frame)))) (cond ((or (and (fboundp 'menu-or-popup-active-p) (menu-or-popup-active-p)) - (and window + (> (minibuffer-depth) 0) + (and window (let ((coords (coordinates-in-window-p (cdr mouse-position) window))) (and (not (consp coords))
> Cc: gregory@heytings.org, robert@capuchin.co.uk, 47969@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Mon, 3 May 2021 19:31:30 +0200
>
> You mean your earlier
>
> > FWIW, I think we should instead temporarily disable
> > mouse-autoselect-window when a minibuffer is active.
>
> as in the untested below?
Something like that (I didn't yet have time to test the patch).
My reasoning is simple: switching windows by a keyboard command or by
clicking the mouse is an intentional user action, for which he/she is
fully responsible. By contrast, moving the mouse pointer can be
accidental, so disabling only it in these situations makes much more
sense than disabling window-switch entirely.
Yet another alternative would be to treat the select-window event in
the middle of a key sequence specially, but I'm afraid that would be a
much more complex and dangerous change (as everything inside
read_char).
>> You mean your earlier >> >>> FWIW, I think we should instead temporarily disable >>> mouse-autoselect-window when a minibuffer is active. >> >> as in the untested below? > > Something like that (I didn't yet have time to test the patch). > I see what you mean, but that patch at least doesn't work; apparently with this recipe mouse-autoselect-window-select is never called. And the problem is that between ESC and x minibuffer-depth is still = 0. > > My reasoning is simple: switching windows by a keyboard command or by > clicking the mouse is an intentional user action, for which he/she is > fully responsible. By contrast, moving the mouse pointer can be > accidental, so disabling only it in these situations makes much more > sense than disabling window-switch entirely. > My patch does not disable window-switching entirely, an explicit mouse click works: ESC mouse-1 is undefined, but the window in which the click happens is selected. After pressing ESC, keyboard commands do not do run what one would expect, e.g. C-x o does not run other-window but (in an Elisp buffer) eval-defun (i.e. C-M-x) followed by self-insert-command ('o').
> Date: Tue, 04 May 2021 07:41:53 +0000 > From: Gregory Heytings <gregory@heytings.org> > cc: martin rudalics <rudalics@gmx.at>, 47969@debbugs.gnu.org, > robert@capuchin.co.uk > > > My reasoning is simple: switching windows by a keyboard command or by > > clicking the mouse is an intentional user action, for which he/she is > > fully responsible. By contrast, moving the mouse pointer can be > > accidental, so disabling only it in these situations makes much more > > sense than disabling window-switch entirely. > > My patch does not disable window-switching entirely, an explicit mouse > click works: ESC mouse-1 is undefined, but the window in which the click > happens is selected. The problem is that you suggest to change handle-select-window which is a general interactive function that has a "key" binding. I'd like to restrict the effect of the change only to auto-selection of windows by the mouse, because I see no reason to make the effect more broad. > After pressing ESC, keyboard commands do not do run what one would expect, > e.g. C-x o does not run other-window but (in an Elisp buffer) eval-defun > (i.e. C-M-x) followed by self-insert-command ('o'). Sorry, I don't think I understand what you are trying to say here, nor how it is relevant to the issue at hand. Please clarify.
>>> My reasoning is simple: switching windows by a keyboard command or by >>> clicking the mouse is an intentional user action, for which he/she is >>> fully responsible. By contrast, moving the mouse pointer can be >>> accidental, so disabling only it in these situations makes much more >>> sense than disabling window-switch entirely. >> >> My patch does not disable window-switching entirely, an explicit mouse >> click works: ESC mouse-1 is undefined, but the window in which the >> click happens is selected. > > The problem is that you suggest to change handle-select-window which is > a general interactive function that has a "key" binding. I'd like to > restrict the effect of the change only to auto-selection of windows by > the mouse, because I see no reason to make the effect more broad. > Okay. The problem is that mouse-autoselect-window-select is not called with mouse-autoselect-window t, the autoselection is immediate. So handle-select-window is called immediately, and AFAICS there is at that point no way to detect whether the select-window event came from an autoselection or from an explicit selection. What I would do to narrow the possible effect is to replace the (window-minibuffer-p) in my patch with (and mouse-autoselect-window (window-minibuffer-p)) Would you agree with that? >> After pressing ESC, keyboard commands do not do run what one would >> expect, e.g. C-x o does not run other-window but (in an Elisp buffer) >> eval-defun (i.e. C-M-x) followed by self-insert-command ('o'). > > Sorry, I don't think I understand what you are trying to say here, nor > how it is relevant to the issue at hand. Please clarify. > I replied to your "switching windows by a keyboard command [...] is an intentional user action", to mention that in this particular case (after pressing ESC) the keyboard commands to switch windows do not behave as expected (unlike clicking). Indeed this was not directly relevant to the issue at hand.
> Date: Tue, 04 May 2021 13:04:58 +0000 > From: Gregory Heytings <gregory@heytings.org> > cc: rudalics@gmx.at, 47969@debbugs.gnu.org, robert@capuchin.co.uk > > > The problem is that you suggest to change handle-select-window which is > > a general interactive function that has a "key" binding. I'd like to > > restrict the effect of the change only to auto-selection of windows by > > the mouse, because I see no reason to make the effect more broad. > > Okay. The problem is that mouse-autoselect-window-select is not called > with mouse-autoselect-window t, the autoselection is immediate. So > handle-select-window is called immediately, and AFAICS there is at that > point no way to detect whether the select-window event came from an > autoselection or from an explicit selection. What I would do to narrow > the possible effect is to replace the > > (window-minibuffer-p) > > in my patch with > > (and mouse-autoselect-window (window-minibuffer-p)) > > Would you agree with that? Yes, this is better. But I wonder if we can do better yet. I see that we already have machinery in place to delay auto-selection for some reason or other -- can we use this feature in this case, perhaps? See mouse-autoselect-window-state and its users. Perhaps we can delay the auto-selection until after the key sequence started by ESC is processed? > >> After pressing ESC, keyboard commands do not do run what one would > >> expect, e.g. C-x o does not run other-window but (in an Elisp buffer) > >> eval-defun (i.e. C-M-x) followed by self-insert-command ('o'). > > > > Sorry, I don't think I understand what you are trying to say here, nor > > how it is relevant to the issue at hand. Please clarify. > > > > I replied to your "switching windows by a keyboard command [...] is an > intentional user action", to mention that in this particular case (after > pressing ESC) the keyboard commands to switch windows do not behave as > expected (unlike clicking). Ah, you mean only keys from special-event-map will have such an effect. Most probably, yes.
>> What I would do to narrow the possible effect is to replace the
>>
>> (window-minibuffer-p)
>>
>> in my patch with
>>
>> (and mouse-autoselect-window (window-minibuffer-p))
>>
>> Would you agree with that?
>
> Yes, this is better. But I wonder if we can do better yet. I see that
> we already have machinery in place to delay auto-selection for some
> reason or other -- can we use this feature in this case, perhaps? See
> mouse-autoselect-window-state and its users. Perhaps we can delay the
> auto-selection until after the key sequence started by ESC is processed?
>
Would doing that not contradict the docstring of mouse-autoselect-window,
which says: "Autoselection [...] never unselects the minibuffer if it is
active."?
> Date: Tue, 04 May 2021 13:26:53 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: rudalics@gmx.at, 47969@debbugs.gnu.org, robert@capuchin.co.uk
>
>
> > Yes, this is better. But I wonder if we can do better yet. I see that
> > we already have machinery in place to delay auto-selection for some
> > reason or other -- can we use this feature in this case, perhaps? See
> > mouse-autoselect-window-state and its users. Perhaps we can delay the
> > auto-selection until after the key sequence started by ESC is processed?
> >
>
> Would doing that not contradict the docstring of mouse-autoselect-window,
> which says: "Autoselection [...] never unselects the minibuffer if it is
> active."?
I don't think so, because the selection will be after the user exits
minibuffer? Or what am I missing?
>>> Yes, this is better. But I wonder if we can do better yet. I see
>>> that we already have machinery in place to delay auto-selection for
>>> some reason or other -- can we use this feature in this case, perhaps?
>>> See mouse-autoselect-window-state and its users. Perhaps we can delay
>>> the auto-selection until after the key sequence started by ESC is
>>> processed?
>>
>> Would doing that not contradict the docstring of
>> mouse-autoselect-window, which says: "Autoselection [...] never
>> unselects the minibuffer if it is active."?
>
> I don't think so, because the selection will be after the user exits
> minibuffer? Or what am I missing?
>
Indeed, with that understanding there is no contradiction. But what
"autoselection [...] never unselects the minibuffer if it is active" means
in practice is that autoselection is disabled while the minibuffer is
active. If you M-x, move the mouse to another window, type a command and
RET, no autoselection happens. I'm not sure that the complexity of what
you suggest is worth the price for this specific case (ESC x instead of
M-x), given what the behavior is with M-x.
> Date: Tue, 04 May 2021 14:43:01 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: rudalics@gmx.at, 47969@debbugs.gnu.org, robert@capuchin.co.uk
>
> Indeed, with that understanding there is no contradiction. But what
> "autoselection [...] never unselects the minibuffer if it is active" means
> in practice is that autoselection is disabled while the minibuffer is
> active. If you M-x, move the mouse to another window, type a command and
> RET, no autoselection happens. I'm not sure that the complexity of what
> you suggest is worth the price for this specific case (ESC x instead of
> M-x), given what the behavior is with M-x.
I'm not sure either, but let's hear Martin at least, and I hope Lars
as well, on that idea.
If we eventually go back to your last proposal, I think it would be
slightly better to test that the selection was invoked via
select-window "key", instead of testing the mode.
>> Indeed, with that understanding there is no contradiction. But what >> "autoselection [...] never unselects the minibuffer if it is active" means >> in practice is that autoselection is disabled while the minibuffer is >> active. If you M-x, move the mouse to another window, type a command and >> RET, no autoselection happens. I'm not sure that the complexity of what >> you suggest is worth the price for this specific case (ESC x instead of >> M-x), given what the behavior is with M-x. > > I'm not sure either, but let's hear Martin at least, and I hope Lars > as well, on that idea. I have no good idea here but note one aspect: When a user has the minibuffer on a separate frame and her WM does focus-follows-mouse, moving the mouse between frames will select another window. I doubt that we can impose any restrictions for minibuffer dialogues in such case so we have an inconsistency. Basically, it all boils down to whether we want our minibuffer interactions be modal or not. I sometimes start a dialogue and, in order to finish it, look into some other buffer and maybe even start some recursive dialogue before returning to the prior one. While doing that I probably would like autoselection to behave as usual. OTOH a strictly modal dialogue like `yes-or-no-p' should probably disallow autoselection. martin
>>> Indeed, with that understanding there is no contradiction. But what >>> "autoselection [...] never unselects the minibuffer if it is active" >>> means in practice is that autoselection is disabled while the >>> minibuffer is active. If you M-x, move the mouse to another window, >>> type a command and RET, no autoselection happens. I'm not sure that >>> the complexity of what you suggest is worth the price for this >>> specific case (ESC x instead of M-x), given what the behavior is with >>> M-x. >> >> I'm not sure either, but let's hear Martin at least, and I hope Lars as >> well, on that idea. > > I have no good idea here but note one aspect: When a user has the > minibuffer on a separate frame and her WM does focus-follows-mouse, > moving the mouse between frames will select another window. > Are you sure? I just tried it (I enabled focus-follows-mouse in both my WM and Emacs and mouse-autoselect-window in Emacs), and with Emacs 25 (i.e. before 3fdd3bb56c) and with Emacs 28 with my patch, moving the mouse between ESC and x, or even later, does not select another window. The user input is redirected to the minibuffer, even when it is not the currently selected frame by the WM. > > I sometimes start a dialogue and, in order to finish it, look into some > other buffer and maybe even start some recursive dialogue before > returning to the prior one. While doing that I probably would like > autoselection to behave as usual. > Is autoselection really necessary? An click does the job in this case: the window in which the click happened is selected, and the minibuffer is suspended.
>> I have no good idea here but note one aspect: When a user has the minibuffer on a separate frame and her WM does focus-follows-mouse, moving the mouse between frames will select another window. >> > > Are you sure? No. > I just tried it (I enabled focus-follows-mouse in both my WM and Emacs and mouse-autoselect-window in Emacs), and with Emacs 25 (i.e. before 3fdd3bb56c) and with Emacs 28 with my patch, moving the mouse between ESC and x, or even later, does not select another window. The user input is redirected to the minibuffer, even when it is not the currently selected frame by the WM. What is your value of `focus-follows-mouse'? Also my WM does auto-raise a frame whenever it gets focus. And finally there's Bug#16681. > Is autoselection really necessary? An click does the job in this case: the window in which the click happened is selected, and the minibuffer is suspended. I never use double-clicks. So clicking into any window usually means to move the cursor to the position where I'm clicking at. Focus follows mouse avoids that. And within Emacs I'm using mouse autoselection to avoid that point moves to the position I click at. IIRC we have some workaround on X to avoid that but I didn't like it because I want single mouse clicks to set point. martin
>>> I have no good idea here but note one aspect: When a user has the >>> minibuffer on a separate frame and her WM does focus-follows-mouse, >>> moving the mouse between frames will select another window. >> >> Are you sure? > > No. > ;-) >> I just tried it (I enabled focus-follows-mouse in both my WM and Emacs >> and mouse-autoselect-window in Emacs), and with Emacs 25 (i.e. before >> 3fdd3bb56c) and with Emacs 28 with my patch, moving the mouse between >> ESC and x, or even later, does not select another window. The user >> input is redirected to the minibuffer, even when it is not the >> currently selected frame by the WM. > > What is your value of `focus-follows-mouse'? Also my WM does auto-raise > a frame whenever it gets focus. > As I said, its value is t. My WM also auto-raises a frame whenever it gets focus, but in spite of this it is the non-raised frame (the minibuffer one) that gets the user input. > > And finally there's Bug#16681. > I wasn't aware of that bug. I just tried it, and I can't reproduce it, it works correctly with and without focus-follows-mode t, so it seems to be fixed.
>> What is your value of `focus-follows-mouse'? Also my WM does auto-raise a frame whenever it gets focus. >> > > As I said, its value is t. You're right, I missed that. > My WM also auto-raises a frame whenever it gets focus, but in spite of this it is the non-raised frame (the minibuffer one) that gets the user input. OK. So let's do whatever you consider TRT here. martin
> Cc: 47969@debbugs.gnu.org, robert@capuchin.co.uk
> From: martin rudalics <rudalics@gmx.at>
> Date: Wed, 5 May 2021 09:25:26 +0200
>
> Basically, it all boils down to whether we want our minibuffer
> interactions be modal or not. I sometimes start a dialogue and, in
> order to finish it, look into some other buffer and maybe even start
> some recursive dialogue before returning to the prior one. While doing
> that I probably would like autoselection to behave as usual. OTOH a
> strictly modal dialogue like `yes-or-no-p' should probably disallow
> autoselection.
The problem here is that Emacs is unable to react reasonably to
autoselection in the middle of reading a key sequence. So modal or
not, we simply cannot support the kind of excursions that you like to
make until the key sequence being read was read in its entirety. Note
that this doesn't necessarily mean we exit the minibuffer, so we could
still support non-modal prompts. But we cannot do that between ESC
and the rest of the sequence, or between C-x and the rest, or in any
other situation when the user pressed one or more prefix keys, because
we have only one channel for reading keys, and we loop there until we
have a complete sequence that maps to some command.
My suggestion was to disable (or delay) mouse autoselection until the
key sequence is completely read, if that's possible.
> My suggestion was to disable (or delay) mouse autoselection until the > key sequence is completely read, if that's possible. Mouse autoselection is completely in Elisp. Do we have any means to control the state of reading a key sequence from Elisp? martin
> Cc: gregory@heytings.org, 47969@debbugs.gnu.org, robert@capuchin.co.uk
> From: martin rudalics <rudalics@gmx.at>
> Date: Thu, 6 May 2021 09:44:16 +0200
>
> > My suggestion was to disable (or delay) mouse autoselection until the
> > key sequence is completely read, if that's possible.
>
> Mouse autoselection is completely in Elisp. Do we have any means to
> control the state of reading a key sequence from Elisp?
I don't know; I don't think so. But the solution doesn't have to be
entirely in Lisp, does it? We could, for example, add a variable
indicating that a key sequence is being read (if there isn't such a
variable already).
Stefan, any suggestions or comments?
> I don't know; I don't think so. But the solution doesn't have to be > entirely in Lisp, does it? We could, for example, add a variable > indicating that a key sequence is being read (if there isn't such a > variable already). [ I don't think there's such a variable, no. ] > Stefan, any suggestions or comments? No, the thread looks pretty complete. I'll just point out that it's OK to revert the change made for Emacs-25, but at one condition: we need to clearly label the `minibufferp` test with a comment pointing to this discussion so that if the problem that commit was intended to fix comes up again, we'll then have more context to make a better decision. Actually, one idea: this problem seems linked to accidental mouse movement, so its occurrence depends on the kind of input device you use as well as the user's usage patterns, so we could let `mouse-autoselect-window` have 3 values, for those users who want to support `mouse-autoselect-window` even from inside an active minibuffer. Stefan
>> Stefan, any suggestions or comments?
>
> No, the thread looks pretty complete.
>
> I'll just point out that it's OK to revert the change made for Emacs-25,
> but at one condition: we need to clearly label the `minibufferp` test
> with a comment pointing to this discussion so that if the problem that
> commit was intended to fix comes up again, we'll then have more context
> to make a better decision.
>
I have one more comment: the code that was removed from
handle-select-window by commit 3fdd3bb56c:
;; Don't switch if we're currently in the minibuffer.
;; This tries to work around problems where the
;; minibuffer gets unselected unexpectedly, and where
;; you then have to move your mouse all the way down to
;; the minibuffer to select it.
(window-minibuffer-p)
was added by that same commit in xterm.c:
/* Don't switch if we're currently in the minibuffer.
This tries to work around problems where the
minibuffer gets unselected unexpectedly, and where
you then have to move your mouse all the way down to
the minibuffer to select it. */
&& !MINI_WINDOW_P (XWINDOW (selected_window))
but, at least for the recipe of this bug, this code movement does not
produce the expected effect.
Note also that this condition is not present the corresponding code in
nsterm.m and w32term.c.
> I have one more comment: the code that was removed from handle-select-window > by commit 3fdd3bb56c: > > ;; Don't switch if we're currently in the minibuffer. > ;; This tries to work around problems where the > ;; minibuffer gets unselected unexpectedly, and where > ;; you then have to move your mouse all the way down to > ;; the minibuffer to select it. > (window-minibuffer-p) IIUC this condition was tested when we actually tried to select the other window, i.e. "at the end of `ESC x`". > was added by that same commit in xterm.c: > > /* Don't switch if we're currently in the minibuffer. > This tries to work around problems where the > minibuffer gets unselected unexpectedly, and where > you then have to move your mouse all the way down to > the minibuffer to select it. */ > && !MINI_WINDOW_P (XWINDOW (selected_window)) Whereas this condition is now tested when the mouse movement takes place, i.e. betwen `ESC` and `x`, at which point the minibuffer is not yet activated. Stefan
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: martin rudalics <rudalics@gmx.at>, gregory@heytings.org,
> 47969@debbugs.gnu.org, robert@capuchin.co.uk
> Date: Thu, 06 May 2021 09:22:52 -0400
>
> > I don't know; I don't think so. But the solution doesn't have to be
> > entirely in Lisp, does it? We could, for example, add a variable
> > indicating that a key sequence is being read (if there isn't such a
> > variable already).
>
> [ I don't think there's such a variable, no. ]
>
> > Stefan, any suggestions or comments?
>
> No, the thread looks pretty complete.
What do you think about the idea of handling the select-window event
the same as we handle the select-frame event during the key sequence?
For example, type C-x, then cause the select-frame event by a suitable
mouse gesture (here I have focus follow mouse, so just moving the
mouse to another frame causes that), then type C-x again. This
produces "C-x C-x" which works on the buffer shown in the selected
window of the frame to which I moved the mouse.
Can we do something similar with mouse-autoselect-window?
> What do you think about the idea of handling the select-window event
> the same as we handle the select-frame event during the key sequence?
> For example, type C-x, then cause the select-frame event by a suitable
> mouse gesture (here I have focus follow mouse, so just moving the
> mouse to another frame causes that), then type C-x again. This
> produces "C-x C-x" which works on the buffer shown in the selected
> window of the frame to which I moved the mouse.
>
> Can we do something similar with mouse-autoselect-window?
We could do that, yes. The downside is that this requires special
handling in src/keyboard.c, which is ... delicate ;-)
But since it will presumably just parallel the way we handle
SWITCH_FRAME, it shouldn't be too bad.
Stefan
[-- Attachment #1: Type: text/plain, Size: 322 bytes --] > > We could do that, yes. The downside is that this requires special > handling in src/keyboard.c, which is ... delicate ;-) > I don't think it is really useful to add such a special handling to fix this bug (but it could make sense to add it later). I attach the updated patch, which I think does the right thing. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: Type: text/x-diff; name=Do-not-switch-to-other-window-when-minibuffer-is-sel.patch, Size: 1207 bytes --] From 84a44926c3e5754f73116ee4ae95b01bf1f3dac3 Mon Sep 17 00:00:00 2001 From: Gregory Heytings <gregory@heytings.org> Date: Tue, 25 May 2021 08:46:46 +0000 Subject: [PATCH] Do not switch to other window when minibuffer is selected * lisp/window.el (handle-select-window): Do not silently switch to other window when minibuffer is selected and mouse-autoselect-window is t (Bug#47969). --- lisp/window.el | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lisp/window.el b/lisp/window.el index 0f94d8a214..fd1c617d6b 100644 --- a/lisp/window.el +++ b/lisp/window.el @@ -10055,6 +10055,9 @@ handle-select-window ;; already selected. (and (not (eq frame (selected-frame))) (frame-parameter frame 'no-accept-focus)) + ;; Don't switch if window autoselection with mouse is active + ;; and minibuffer window is selected. + (and mouse-autoselect-window (window-minibuffer-p)) ;; Don't switch to minibuffer window unless it's active. (and (window-minibuffer-p window) (not (minibuffer-window-active-p window)))) -- 2.30.2
Gregory Heytings <gregory@heytings.org> writes: > I don't think it is really useful to add such a special handling to > fix this bug (but it could make sense to add it later). I attach the > updated patch, which I think does the right thing. I only lightly skimmed this long thread, but this patch makes sense to me, so I've now pushed it to Emacs 28. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no