Re: "Final" version of tty child frames

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: martin rudalics <rudalics@gmx.at>,  jared@finder.org,  emacs-devel@gnu.org
> Date: Thu, 16 Jan 2025 05:35:13 +0100
> 
> When inserting a character, a desired glyph row is built. That row can
> be used to set the cursor.
> 
> When just moving the cursor, no desired glyphs are produced, and the
> current glyph row is used, which can contain glyphs from child frames.

The current glyph row which can contain glyphs from a child frame is a
glyph row of the frame's current matrix.  But try_cursor_movement uses
the _window's_ current matrix.  Are you saying that, due to glyph row
sub-allocation on TTY frames, the glyphs from the child frame "seep"
into the current glyph matrix of the parent frame's windows?  If so,
this could cause many problems, so we could prevent that somehow, in
which case set_cursor_from_row could be kept unaltered.

Alternatively, set_cursor_from_row should be modified to deal with
glyphs from another frame.  Then it will be able to work correctly
both on desired and on current glyph rows.  But then the question is
what do we expect from set_cursor_from_row to do when the correct
position of the cursor is obscured by the child frame?
set_cursor_from_row produces two results: it returns a boolean that is
true if the cursor should be placed on the glyph row passed to it,
false otherwise; and it sets the w->cursor fields if it returns true.
If this should still be the case when a child frame conceals the
cursor position on its parent frame, we need to see how to do that
when the glyph row doesn't include the glyphs from the window passed
to the function.  Alternatively, we could do something special in this
case (but what?), since the cursor will not be drawn anyway.