Re: "Final" version of tty child frames

[martin rudalics]

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

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

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

martin