Re: "Final" version of tty child frames

[Eli Zaretskii]

> Date: Fri, 17 Jan 2025 16:09:22 +0100
> Cc: gerd.moellmann@gmail.com, jared@finder.org, emacs-devel@gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
>  > It is shown because we iterate from the beginning of the screen line,
>  > even if it is obscured.  During that iteration, we pay attention to
>  > all the display and overlay properties, but do not produce glyphs.
> 
> That's the iterator code.  But here we talk about a cursor producing
> code which starts, if I'm not totally mistaken, at the first glyph of a
> row.

The code in set_cursor_from_row only examines the glyphs, yes.  The
part hidden by hscrolling doesn't produce any glyphs.

>  > We could.  But the problem here is that the above code runs waaay
>  > before we combine glyph matrices, and doesn't know anything about the
>  > special case of TTY child frames.
> 
> Agreed.  Then the problem must be solved in the iterator code _before_
> glyphs are produced.

What problem is that?

>  > And frankly, I don't understand the reason for the problem: by the
>  > time we combine frame matrices, the glyphs produced from the display
>  > property are already in the matrix, so it sounds like all we need is
>  > to leave those glyphs alone where the child matrix doesn't conceal the
>  > parent?  Or what am I missing?
> 
> The problem is a very tiny one: When setting the cursor from the row we
> should be able to set it in the visible part right of a child frame (with
> RL text left of it) that obscures the basic frame.

And why is that a problem?  (It's an honest question: I don't
understand what prevents you from finding the correct cursor position
in this case.  I guess some details of the problem were not described
yet, at least not in terms that I could understand it.)