Re: "Final" version of tty child frames

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 05 Jan 2025 16:05:59 -0800
> From: Jared Finder <jared@finder.org>
> Cc: gerd.moellmann@gmail.com, emacs-devel@gnu.org, rudalics@gmx.at
> 
> 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. :)

FTR, they are not Emacs conventions, they are GNU conventions.

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

Maybe term_mouse_position should return immediately if GPM is not
enabled?

> >> +{
> >> +  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?

Yes, I think so.