Re: "Final" version of tty child frames

[Jared Finder <jared@finder.org>]

On 2025-01-04 23:07, Eli Zaretskii wrote:
>> Date: Sat, 04 Jan 2025 14:12:00 -0800
>> From: Jared Finder <jared@finder.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org, rudalics@gmx.at
>> 
>> It was that easy to do.  Attached is a patch that adds support for TTY
>> child frames to a GPM mouse.
> 
> Thanks.

Style comments addressed, thank you! Someday, I will internalize Emacs' 
unique C style conventions.  Probably once I only code for Emacs and not 
other projects. :)

>> @@ -2638,7 +2639,11 @@ term_mouse_position (struct frame **fp, int 
>> insist, Lisp_Object *bar_window,
>>  		     enum scroll_bar_part *part, Lisp_Object *x,
>>  		     Lisp_Object *y, Time *timeptr)
>>  {
>> -  *fp = SELECTED_FRAME ();
>> +  /* This code runs even when `gpm-mouse-mode' was never active, like
>> +     inside an xterm.  In such cases, last_mouse_frame will never be
>> +     set, so fallback to SELECTED_FRAME. */
>> +  *fp = FRAMEP (last_mouse_frame) ? XFRAME (last_mouse_frame)
>> +    : SELECTED_FRAME ();
> 
> Does this mean child frames on xterm will have the selected-frame set
> to a child frame, and thus do not need this trick with
> last_mouse_frame?  Or what other difference between xterm and the
> Linux console hides behind this "fallback"?

This is just keeping the behavior that already exists today.  I was 
surprised by the current behavior: that term_mouse_position which only 
works for a GPM enabled mouse gets called even when GPM could not be 
used.  It could make sense to change this behavior however it would be a 
bigger change as gpm-mouse-mode is enabled by default even for non-GPM 
supporting terminals.  I suspect that GPM support is equivalent to 
TERM=linux, but I may be wrong.

This works when xterm-mouse-mode is enabled because mouse_position_hook 
(set to term_mouse_position) is called first, followed by 
mouse-position-function (set to xterm-mouse-position-function).  On ttys 
with xterm-mouse-mode enabled the return value from term_mouse_position 
is ignored.  See existing definitions in Fmouse_pixel_position and 
mouse_position in frame.c.

>> +{
>> +  Lisp_Object frame = CALLN (Ffuncall, Qframe_at,
>> +			     make_fixnum (x), make_fixnum (y));
> 
> I'd refrain from calling into Lisp here: frame-at will call
> tty-frame-list-z-order, which is implemented in C, and the rest of
> frame-at can be trivially done in C.

Would it make sense to delete the Lisp implementation of frame-at and 
make it implemented in C only? The only other existing client of 
frame-at is xterm-mouse-mode for the same use case.  Looking forward, I 
expect that getting a window by screen pixel coordinate will be less 
available over time.  Wayland and Android specifically do not support 
this for arbitrary pixels for security reasons.

   -- MJF