bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Jared Finder
Subject: bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal
Date: Thu, 28 Mar 2024 07:41:28 -0700

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?

  -- MJF





reply via email to

[Prev in Thread] Current Thread [Next in Thread]