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 22:03:54 +0100
> 
> 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 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.
> 
> Okay, but the vpos has already been determined in set_cursor_from_row,
> right?

Not necessarily.  When I developed the auto-hscroll-mode =
current-line feature, I remember sometimes bumping into cases, when
typing C-n or C-p, that vpos was still negative when entering
display_line, which means it could be negative in set_cursor_from_row.

> And set_cursor_from_row should not touch vpos/y.

I meant w->cursor.vpos, not vpos of the row or the iterator:

  w->cursor.hpos = glyph - row->glyphs[TEXT_AREA];
  w->cursor.x = x;
  w->cursor.vpos = MATRIX_ROW_VPOS (row, matrix) + dvpos;
  w->cursor.y = row->y + dy;

> > 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.
> 
> AFAIU, this also requires desired glyphs to be built. So I think this
> should work too.

The code in set_cursor_from_row doesn't currently distinguish between
the current and desired matrices.

> >> > 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.
> 
> I made "row" const in set_cursor_from_row like so, to be sure
> 
>     static bool
>     set_cursor_from_row (struct window *w, struct glyph_row *const row,
> 
> to make sure that 'row' is indeed not changed in the function. Which means
> the decision about that is made in a caller. And I would expect that is
> done by using the height of the row (which is 1).

That's not what I meant.  'row' is indeed changed only by the caller
of set_cursor_from_row, but the decision whether 'row' is the cursor
row is done by set_cursor_from_row, and it indicates that by setting
the w->cursor fields, as shown in the code fragment above.

> > 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?
> 
> That I'm not 100% sure of because I don't grasp set_cursor_from_row
> completely. The glyphs of a display string have the frame set like other
> glyphs have (see produce_glyphs and subroutines). I think we skip over
> glyphs from strings, if I read that correctly, and stop after them.

Right.  But the glyph->frame test in Martin's patch seems to be done
only where we examine glyphs whose OBJECT is a buffer, and thus we can
compare their CHARPOS to point.  The code which follows that examines
glyphs from strings, but there's no glyph->frame test there, AFAICT.
So if we bump into a glyph from the child frame in the middle of
examining glyphs from a string, we could fail to notice that until
later.

> If that's a glyph from a buffer. and glyph->frame != f we're under a
> child, else not. Like I said, I'd bet only a small amount on that,
> perhaps you and Martin could also check?

My question was a suggestion to check this, yes.