Re: "Final" version of tty child frames

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: rudalics@gmx.at,  jared@finder.org,  emacs-devel@gnu.org
> Date: Thu, 16 Jan 2025 09:42:27 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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.

Yes.  Its advantage is that then set_cursor_from_row could be left
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?
> 
> 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?

The value it returns is not enough, because w->cursor fields are
accessed in other places.  So it sounds like a separate frame matrix
would be a better, easier (and cleaner) solution.

> It would have to look carefully though, and cannot
> just give up on the first child frame glyph it encounters.

Yes, it will have to treat that as glyphs that came from a string, and
skip them.

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

If we do that, i.e. set w->cursor.x negative, which is an indication
that the cursor position of the window is unknown, we'd need to make
sure set_cursor_from_row is called when the underlying frame is
exposed.  So the separate-matrix alternative still sounds simpler.