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 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? And set_cursor_from_row should not touch vpos/y.

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

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

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

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