bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal

[Eli Zaretskii]

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

> > I also commented out a condition, which ensures that the selection of a 
> > window can only occur, if the mouse is in the text area of the window. 
> > This matches the following sentence of the documentation:
> > "In either case, the mouse pointer must enter the text area of a window 
> > in order to trigger its selection."
> > But I found no situation, where it did matter and msdos.c didn't have 
> > that test, either. WDYT?
> 
> I think the documentation is incorrect and this commented out case 
> should be removed.  Local testing on PGTK and Mac shows that the mouse 
> pointer can be over the window dividers, widget scroll bars, or fringes 
> and still have autoselect behavior activate.

Is this at all relevant for TTY frames?  Everything is "text area" on
TTY frames, right?  If not, what are the use cases where the mouse
would be "not in the text area" on a TTY frame, in the context of
auto-selecting a window?

> >> > +           (progn
> >> > +             (put 'select-window 'event-kind 'switch-frame)
> >> > +             (setf (car event) 'select-window)
> >> > +             vec)
> >> > I think this should be an event that's just select-window and the 
> >> > window, to line up with what the select-window event looks like on other 
> >> > platforms (I tested PGTK and Windows terminal).  You can verify this by 
> >> > running M-x trace-function RET handle-select-window RET.
> >> > That would instead be something like:
> >> > (progn
> >>   (put 'select-window 'event-kind 'switch-frame)
> >>   (vector `(select-window (,ev-window)))
> > 
> > I can't find the documentation of the format of the select-window 
> > event. Maybe its a good idea to add it.
> 
> Agreed.  I think it should be added to Focus Events in commands.texi.

I agree.

> > Please find below the next iteration of the patch.
> 
> Assuming above comments are addressed, this looks good to me.  I imagine 
> there will be minor comment reformatting to avoid going beyond 80 
> columns.

Thanks, please post the final version after these minor changes for
review.

Thanks.