GNU bug report logs - #69915
30.0.50; mouse-autoselect-window has no effect in terminal

Previous Next

Package: emacs;

Reported by: Olaf Rogalsky <olaf.rogalsky <at> t-online.de>

Date: Wed, 20 Mar 2024 14:56:01 UTC

Severity: normal

Found in version 30.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, Jared Finder <jared <at> finder.org>
Cc: olaf.rogalsky <at> gmail.com, 69915 <at> debbugs.gnu.org
Subject: Re: bug#69915: 30.0.50; mouse-autoselect-window has no effect in
 terminal
Date: Mon, 1 Apr 2024 11:09:47 +0200
>> The intended behavior is that is even with mouse-autoselect-window set,
>> moving the mouse is never supposed to change the selected window away
>> from the minibuffer.  Many platforms explicitly check if the selected
>> window is the minibuffer before emitting the <select-window> event, but
>> not all platforms do (see list above).
>>
>> And on all platforms, including ones without the explicit check we get
>> the intended behavior from our testing.
>>
>> So my question is should we copy the explicit check to prevent
>> <select-window> events from being emitted to xt-mouse.el as well, even
>> though it does not appear to be necessary from our testing?
>
> The mini-window test was added by Martin, AFAICT, as part of rewriting
> the mouse-autoselect-window support.  Martin, do you remember why you
> added the MINI_WINDOW_P test in xterm.c, but not, for example, in
> w32term.c?
>
> In any case, I couldn't find any problems with the current behavior on
> MS-Windows when mouse-autoselect-window is non-nil.

The original mini-window test was conceived by Stefan

commit 66c226bf5a1e8289b0ce676d5e4225810a11af91
Author: Stefan Monnier <monnier <at> iro.umontreal.ca>
Date:   Thu Jan 20 14:23:23 2005 +0000

    (handle-select-window): Don't switch window when we're in the minibuffer.

and I moved it to xterm.c later.  I don't remember why and all I
remember is that the accompanying comment was not mine.

The check is redundant because the condition is tested again here in
'handle-select-window':

                ;; Don't switch if window autoselection with mouse is active
                ;; and minibuffer window is selected.
                (and mouse-autoselect-window (window-minibuffer-p))

One could say that the xterm.c code is more efficient because it doesn't
generate a SELECT_WINDOW_EVENT when the selected window is the
minibuffer window.  The w32 code generates the event but has it
dismissed later in 'handle-select-window'.

In either case I would not remove the check from 'handle-select-window'
because that one is platform-independent so there's no need to implement
anything separately in the backends.

Though it might be more accurate to replace 'window-minibuffer-p' with
'minibuffer-window-active-p' to catch the case where a user, for some
reason, selects the minibuffer window manually without activating the
minibuffer.  And the 'mouse-autoselect-window' conjunct above is likely
redundant...

martin




This bug report was last modified 1 year and 44 days ago.

Previous Next


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