Re: "Final" version of tty child frames

[Eli Zaretskii]

> 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 20:32:17 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Did you try this with auto-hscroll-mode, both set to t and to
> > current-line?  
> 
> If that leads to something being scrolled, we'll have built a desired
> row to display the scrolled result, so that would not be a problematic
> case if we check that the matrix used is the current matrix.

Yes, but the auto-hscroll-mode = current-line case is one of the cases
I remember that rely on w->cursor.vpos for some logic.

Btw, another complication is to do all this testing with
display-line-numbers turned on, especially when Emacs decides to
enlarge the number of digits in a line number, and all the display
of the parent frame needs to scroll horizontally left or right.

> > What happens then if you move cursor with C-n and enter a line which
> > is partially obscured by a child frame? Or if point becomes hidden
> > because it enters the obscure part of the frame from above or below,
> > not from left or from right?
> 
> >From a redisplay perspective, I'd say C-n, C-p, C-b, C-p lead all to the
> same "PT given, find it in glyph row".

Yes, but C-n and C-p change w->cursor.vpos, i.e. set_cursor_from_row
needs to decide that the previous row is no longer a cursor row, and
find the new row.  C-f and C-b don't have that problem.

> >> +  if (is_tty_selected && glyph->charpos > PT)
> >> +    {
> >> +      w->cursor.hpos = -1;
> >> +      w->cursor.x = -1;
> >> +    }
> >
> > Why do you need this test, and specifically the second part of the
> > condition?
> 
> Good question. Something I overlooked.

Here's another one: what happens if the horizontal coordinate where a
child frame starts to hide its parent is in the middle of a display
string or an overlay string?  Does cursor motion then works correctly?