[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal
From: |
Eli Zaretskii |
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@finder.org>
> Cc: olaf.rogalsky@gmail.com, 69915@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@finder.org>
> >> Cc: eliz@gnu.org, 69915@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.