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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jared Finder <jared <at> finder.org>, martin rudalics <rudalics <at> gmx.at>
Cc: olaf.rogalsky <at> gmail.com, 69915 <at> debbugs.gnu.org
Subject: bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal
Date: Sun, 31 Mar 2024 11:58:36 +0300

> Date: Thu, 28 Mar 2024 07:41:28 -0700
> From: Jared Finder <jared <at> finder.org>
> Cc: olaf.rogalsky <at> gmail.com, 69915 <at> debbugs.gnu.org
> 
> On 2024-03-27 23:11, Eli Zaretskii wrote:
> >> Date: Wed, 27 Mar 2024 14:47:27 -0700
> >> From: Jared Finder <jared <at> finder.org>
> >> Cc: eliz <at> gnu.org, 69915 <at> debbugs.gnu.org
> >> 
> >> > On the other hand, looking at msdos.c, there is no test against
> >> > the minibuffer. I believed, that the selection of the minibuffer
> >> > is taken care of at +10638 of window.el. In my tests the patch
> >> > behaves exactly like the documentation, quote: "Mouse
> >> > auto-selection selects the minibuffer window only if it is active,
> >> > and never deselects the active minibuffer window."  I added the
> >> > test, but commented it out.
> >> 
> >> I'm not sure what the right way to proceed here is then.  Eli, can you
> >> give advice?
> >> 
> >> Looking at different OS files that handle mouse_autoselect_window, I 
> >> see
> >> the following state for checks if the selected window is a minibuffer
> >> with MINI_WINDOW_P:
> >> 
> >> pgtkterm.c: checks
> >> w32term.c: does NOT check
> >> w32inevt.c: does NOT check
> >> nsterm.m: checks
> >> xterm.c: checks
> >> msdos.c: does NOT check
> >> haikuterm.c: checks
> >> androidterm.c: checks
> >> term.c: no support for mouse-autoselect-window. :(
> >> 
> >> My gut is to assume that the X and GTK behavior is most likely to be
> >> better tested and more correct, but I defer to Eli here.
> > 
> > I tend to agree.  But, just to be sure, can you or Olaf describe the
> > exact issue and how it could happen, and perhaps show a recipe to try
> > reproducing it?  I'd like to take a closer look at the relevant code.
> 
> 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.

Previous Next

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