Re: "Final" version of tty child frames

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

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

Yes that is so.

> If so, this could cause many problems, so we could prevent that
> somehow, in which case set_cursor_from_row could be kept unaltered.

That's what I propose as an idea in a previous message. Basically, leave
the root's matrices alone, and let the display update use a set of other
matrices for what is displayed and what should be displayed on the
terminal. The desired "terminal matrix" would be built by copying the
root desired matrix, and all of its children.

Something like that. It's just an idea, and I didn't think it through,
but I think it could be a clean solution.

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

That's the question, yes.

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

Maybe it could return not a boolean but an enum with a third value
'invisible' in case it cannot place the cursor anywhere because it finds
child frame glyphs? It would have to look carefully though, and cannot
just give up on the first child frame glyph it encounters. I'd think
that setting the cursor position could be left out. We have only one
cursor on ttys, and it will not end up in that window for the
'invivable' case.