Re: "Final" version of tty child frames

[Eli Zaretskii]

> Date: Sat, 18 Jan 2025 10:04:46 +0100
> Cc: gerd.moellmann@gmail.com, jared@finder.org, emacs-devel@gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
>  > The code in set_cursor_from_row only examines the glyphs, yes.  The
>  > part hidden by hscrolling doesn't produce any glyphs.
> 
> So how does set_cursor_from_row handle the case where
> 
>     BBBBBBBBBBBBBSSSSSSSSSBBBBBBBBB
> 
> is hscrolled somewhere into the middle of the "S"?  That situation is
> the same as if a child frame ended in the middle of these "S".

Why does it matter whether the line is hscrolled or not?  The object
of each glyph is available as glyph->object, and you will see that
set_cursor_from_row processes the case of the object being a buffer or
a string in different ways.  In the case you describe, the first glyph
the function sees will have its object a Lisp string, that's all.
That's not different from a case where there's no hscroll, but a line
begins with a display string at its very beginning.

>  >>   > 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?
> 
> The problem that set_cursor_from_row doesn't know anything about what
> caused the iterator code to produce glyphs in a specific way or order
> and consequently where to place the cursor within these glyphs.

set_cursor_from_row works with what it has: the object recorded by
each glyph and the position in that object.  If there's a gap in
buffer positions recorded in the glyphs, the code will decide to put
the cursor at the first glyph whose buffer position is the closest to
point.  That could be either the one at the right edge of the child
frame or at its left edge (I think the row's reversed_p flag
determines that).

>  >> 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.)
> 
> Have you tried the simple example file I attached previously with the
> recipe I proposed?  Then you should see the problem.

Sorry, I don't have time for this right now.

> When moving via
> C-f in a normal frame that is partially hidden by a child frame, the
> cursor in the normal frame cannot appear at any position on the right of
> the child frame but on the last character of the row.  And this happens
> because set_cursor_from_row has no knowledge of child frames and chokes
> at the first glyph with a nil object.

If the glyph with a nil object belongs to a different frame, the code
should not stop there (I presume by "choke" you mean that the code
exits the loop), but instead try to find another glyph whose object is
either a buffer or a string and whose frame is the window's frame.