GNU bug report logs - #47969
28.0.50; Losing minibuffer focus in trying M-x command

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47969 in the body.
You can then email your comments to 47969 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Robert Marshall <robert <at> capuchin.co.uk>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Fri, 23 Apr 2021 14:00:13 +0100

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))

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Robert Marshall <robert <at> capuchin.co.uk>
Cc: 47969 <at> debbugs.gnu.org
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Sat, 24 Apr 2021 17:29:16 +0000

>
> 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?

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

From: Robert Marshall <robert <at> capuchin.co.uk>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 47969 <at> debbugs.gnu.org
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Sun, 25 Apr 2021 07:41:55 +0100

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

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Robert Marshall <robert <at> capuchin.co.uk>
Cc: 47969 <at> debbugs.gnu.org
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Sun, 25 Apr 2021 09:58:36 +0000

>
> 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?

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

From: Robert Marshall <robert <at> capuchin.co.uk>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 47969 <at> debbugs.gnu.org
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Sun, 25 Apr 2021 13:28:13 +0100

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

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Robert Marshall <robert <at> capuchin.co.uk>
Cc: 47969 <at> debbugs.gnu.org
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Sun, 25 Apr 2021 12:29:27 +0000

>> 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.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Robert Marshall <robert <at> capuchin.co.uk>
Cc: martin rudalics <rudalics <at> gmx.at>, 47969 <at> debbugs.gnu.org
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Sat, 01 May 2021 20:20:16 +0000

[Message part 1 (text/plain, inline)]

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.

[Do-not-switch-to-other-window-when-minibuffer-is-sel.patch (text/x-diff, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: robert <at> capuchin.co.uk, 47969 <at> debbugs.gnu.org
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Sun, 02 May 2021 09:40:42 +0300

> Date: Sat, 01 May 2021 20:20:16 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> Cc: 47969 <at> 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.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Gregory Heytings <gregory <at> heytings.org>,
 Robert Marshall <robert <at> capuchin.co.uk>
Cc: 47969 <at> debbugs.gnu.org
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Sun, 2 May 2021 09:39:55 +0200

> 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

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

From: Robert Marshall <robert <at> capuchin.co.uk>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Gregory Heytings <gregory <at> heytings.org>, 47969 <at> debbugs.gnu.org
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Sun, 2 May 2021 09:01:56 +0100

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

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

From: Gregory Heytings <gregory <at> heytings.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Robert Marshall <robert <at> capuchin.co.uk>, 47969 <at> debbugs.gnu.org
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Mon, 03 May 2021 08:42:28 +0000

>> 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.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gregory Heytings <gregory <at> heytings.org>, 47969 <at> debbugs.gnu.org,
 robert <at> capuchin.co.uk
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Mon, 03 May 2021 11:07:50 +0200

Eli Zaretskii <eliz <at> 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

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

From: martin rudalics <rudalics <at> gmx.at>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Robert Marshall <robert <at> capuchin.co.uk>, 47969 <at> debbugs.gnu.org
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Mon, 3 May 2021 11:38:50 +0200

>> 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

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

From: Gregory Heytings <gregory <at> heytings.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Robert Marshall <robert <at> capuchin.co.uk>, 47969 <at> debbugs.gnu.org
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Mon, 03 May 2021 09:41:05 +0000

>> 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 :(

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

From: Gregory Heytings <gregory <at> heytings.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Robert Marshall <robert <at> capuchin.co.uk>, 47969 <at> debbugs.gnu.org
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Mon, 03 May 2021 11:19:26 +0000

>>> 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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: gregory <at> heytings.org, 47969 <at> debbugs.gnu.org, robert <at> capuchin.co.uk
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Mon, 03 May 2021 14:54:24 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Gregory Heytings <gregory <at> heytings.org>,  robert <at> capuchin.co.uk,
>   47969 <at> 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

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

From: martin rudalics <rudalics <at> gmx.at>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Robert Marshall <robert <at> capuchin.co.uk>, 47969 <at> debbugs.gnu.org
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Mon, 3 May 2021 14:02:13 +0200

> 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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: gregory <at> heytings.org, 47969 <at> debbugs.gnu.org, robert <at> capuchin.co.uk
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Mon, 03 May 2021 15:09:01 +0300

> From: martin rudalics <rudalics <at> gmx.at>
> Date: Mon, 3 May 2021 14:02:13 +0200
> Cc: Robert Marshall <robert <at> capuchin.co.uk>, 47969 <at> 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.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 47969 <at> debbugs.gnu.org,
 robert <at> capuchin.co.uk
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Mon, 03 May 2021 12:15:18 +0000

>> 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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: larsi <at> gnus.org, 47969 <at> debbugs.gnu.org, robert <at> capuchin.co.uk
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Mon, 03 May 2021 15:18:06 +0300

> Date: Mon, 03 May 2021 12:15:18 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: Lars Ingebrigtsen <larsi <at> gnus.org>, robert <at> capuchin.co.uk, 
>     47969 <at> 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.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, robert <at> capuchin.co.uk,
 47969 <at> debbugs.gnu.org
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Mon, 03 May 2021 12:20:46 +0000

>
> 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 :-)

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gregory <at> heytings.org, 47969 <at> debbugs.gnu.org, robert <at> capuchin.co.uk
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Mon, 3 May 2021 19:31:30 +0200

> 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))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: gregory <at> heytings.org, 47969 <at> debbugs.gnu.org, robert <at> capuchin.co.uk
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Mon, 03 May 2021 20:46:56 +0300

> Cc: gregory <at> heytings.org, robert <at> capuchin.co.uk, 47969 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> 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).

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, robert <at> capuchin.co.uk,
 47969 <at> debbugs.gnu.org
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Tue, 04 May 2021 07:41:53 +0000

>> 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').

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: rudalics <at> gmx.at, robert <at> capuchin.co.uk, 47969 <at> debbugs.gnu.org
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Tue, 04 May 2021 14:59:35 +0300

> Date: Tue, 04 May 2021 07:41:53 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: martin rudalics <rudalics <at> gmx.at>, 47969 <at> debbugs.gnu.org, 
>     robert <at> 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.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, robert <at> capuchin.co.uk, 47969 <at> debbugs.gnu.org
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Tue, 04 May 2021 13:04:58 +0000

>>> 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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: rudalics <at> gmx.at, robert <at> capuchin.co.uk, 47969 <at> debbugs.gnu.org
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Tue, 04 May 2021 16:17:19 +0300

> Date: Tue, 04 May 2021 13:04:58 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: rudalics <at> gmx.at, 47969 <at> debbugs.gnu.org, robert <at> 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.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, robert <at> capuchin.co.uk, 47969 <at> debbugs.gnu.org
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Tue, 04 May 2021 13:26:53 +0000

>> 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."?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: rudalics <at> gmx.at, robert <at> capuchin.co.uk, 47969 <at> debbugs.gnu.org
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Tue, 04 May 2021 17:02:53 +0300

> Date: Tue, 04 May 2021 13:26:53 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: rudalics <at> gmx.at, 47969 <at> debbugs.gnu.org, robert <at> 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?

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, robert <at> capuchin.co.uk, 47969 <at> debbugs.gnu.org
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Tue, 04 May 2021 14:43:01 +0000

>>> 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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: rudalics <at> gmx.at, robert <at> capuchin.co.uk, 47969 <at> debbugs.gnu.org
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Tue, 04 May 2021 18:19:30 +0300

> Date: Tue, 04 May 2021 14:43:01 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: rudalics <at> gmx.at, 47969 <at> debbugs.gnu.org, robert <at> 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.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, Gregory Heytings <gregory <at> heytings.org>
Cc: robert <at> capuchin.co.uk, 47969 <at> debbugs.gnu.org
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Wed, 5 May 2021 09:25:26 +0200

>> 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

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

From: Gregory Heytings <gregory <at> heytings.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 47969 <at> debbugs.gnu.org, robert <at> capuchin.co.uk
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Wed, 05 May 2021 09:02:10 +0000

>>> 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.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 47969 <at> debbugs.gnu.org, robert <at> capuchin.co.uk
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Wed, 5 May 2021 11:25:25 +0200

>> 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

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

From: Gregory Heytings <gregory <at> heytings.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 47969 <at> debbugs.gnu.org, robert <at> capuchin.co.uk
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Wed, 05 May 2021 09:40:29 +0000

>>> 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.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 47969 <at> debbugs.gnu.org, robert <at> capuchin.co.uk
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Wed, 5 May 2021 13:24:24 +0200

>> 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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: gregory <at> heytings.org, 47969 <at> debbugs.gnu.org, robert <at> capuchin.co.uk
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Wed, 05 May 2021 15:06:52 +0300

> Cc: 47969 <at> debbugs.gnu.org, robert <at> capuchin.co.uk
> From: martin rudalics <rudalics <at> 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.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gregory <at> heytings.org, 47969 <at> debbugs.gnu.org, robert <at> capuchin.co.uk
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
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?

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: gregory <at> heytings.org, 47969 <at> debbugs.gnu.org, robert <at> capuchin.co.uk
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Thu, 06 May 2021 11:06:58 +0300

> Cc: gregory <at> heytings.org, 47969 <at> debbugs.gnu.org, robert <at> capuchin.co.uk
> From: martin rudalics <rudalics <at> 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?

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, gregory <at> heytings.org,
 47969 <at> debbugs.gnu.org, robert <at> capuchin.co.uk
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
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.

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

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>,
 47969 <at> debbugs.gnu.org, robert <at> capuchin.co.uk
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Thu, 06 May 2021 13:50:48 +0000

>> 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.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>,
 47969 <at> debbugs.gnu.org, robert <at> capuchin.co.uk
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Thu, 06 May 2021 10:18:53 -0400

> 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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: rudalics <at> gmx.at, gregory <at> heytings.org, 47969 <at> debbugs.gnu.org,
 robert <at> capuchin.co.uk
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Sat, 08 May 2021 15:38:27 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: martin rudalics <rudalics <at> gmx.at>,  gregory <at> heytings.org,
>   47969 <at> debbugs.gnu.org,  robert <at> 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?

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, gregory <at> heytings.org, 47969 <at> debbugs.gnu.org,
 robert <at> capuchin.co.uk
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Sat, 08 May 2021 09:36:44 -0400

> 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

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: rudalics <at> gmx.at, Eli Zaretskii <eliz <at> gnu.org>, 47969 <at> debbugs.gnu.org,
 robert <at> capuchin.co.uk
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Tue, 25 May 2021 08:52:04 +0000

[Message part 1 (text/plain, inline)]

>
> 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.

[Do-not-switch-to-other-window-when-minibuffer-is-sel.patch (text/x-diff, attachment)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: robert <at> capuchin.co.uk, 47969 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command
Date: Tue, 25 May 2021 21:40:43 +0200

Gregory Heytings <gregory <at> 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

Previous Next

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