Re: "Final" version of tty child frames

[Eli Zaretskii]

> Date: Fri, 17 Jan 2025 10:09:10 +0100
> Cc: jared@finder.org, emacs-devel@gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
>  > 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?
> 
> I mentioned that in my first post.  Basically, this might be already a
> problem when setting up the combined matrices.  Any display property
> within the underlying frame will have to be on any glyph shown in the
> combined matrix.  Any display property of the covering frame will be
> ignored.

You mean, display properties and overlay strings are not shown on
child frames?  Why not?

> This can be compared to a display property in a normal frame hscrolled
> to the left so the beginning of the line is not visible.  How is a
> display property starting before the first glyph shown on that line
> handled?

It is shown because we iterate from the beginning of the screen line,
even if it is obscured.  During that iteration, we pay attention to
all the display and overlay properties, but do not produce glyphs.
However, the iterator object does get its state updated during that
stage, so when we get to the first glyph whose coordinate is inside
the viewport, and start producing glyphs, we are ready to display as
the user expects.  It's this part at the beginning of display_line
(which is the workhorse of the display engine for layout of screen
lines):

  /* Move over display elements that are not visible because we are
     hscrolled.  This may stop at an x-position < first_visible_x
     if the first glyph is partially visible or if we hit a line end.  */
  if (it->current_x < it->first_visible_x + x_incr)
    {
      enum move_it_result move_result;

      this_line_min_pos = row->start.pos;
      if (hscroll_this_line)
        {
          it->first_visible_x += x_incr;
          it->last_visible_x  += x_incr;
        }
      if (current_buffer->long_line_optimizations_p
          && it->line_wrap == TRUNCATE
          && window_hscroll_limited (it->w, it->f) > large_hscroll_threshold)
        {
          /* Special optimization for very long and truncated lines
             which are hscrolled far to the left: jump directly to the
             (approximate) position that is visible, instead of slowly
             walking there.  */
          [...let's ignore this for the moment...]
        }
      else
        move_result = move_it_in_display_line_to (it, ZV, it->first_visible_x,
                                                  MOVE_TO_POS | MOVE_TO_X);

The call to move_it_in_display_line_to is the one which does what I
described above.

> Then we could do the same for a display property that starts
> in the part of the frame covered by a child frame but extends to the
> visible part following the child frame.

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.

And frankly, I don't understand the reason for the problem: by the
time we combine frame matrices, the glyphs produced from the display
property are already in the matrix, so it sounds like all we need is
to leave those glyphs alone where the child matrix doesn't conceal the
parent?  Or what am I missing?