Re: "Final" version of tty child frames

[Gerd Möllmann]

martin rudalics <rudalics@gmx.at> writes:

>>> It's obvious that this _is_ a redisplay optimization trap.  But it's a
>>> very sophisticated one because the cursor ends up at the correct end of
>>> the line.  With other words C-f does what C-e does.
>>
>> I can suggest two things:
>
> These don't help.  Meanwhile I suppose that it's not related to
> optimizations.  What happens is:
>
> I'm in a base (underlying, normal) frame which is partially covered by a
> child frame.  With 'line-beginning-position' 686 and 'line-end-position'
> 759 and point at 724 I try to move point to position 725 which is the
> first position on that row covered by the child frame.
>
> In set_cursor_from_row at
>
>   if (!((row->reversed_p ? glyph > glyphs_end : glyph < glyphs_end)
>       && BUFFERP (glyph->object) && glyph->charpos == pt_old)
>       && !(bpos_max <= pt_old && pt_old <= bpos_covered))
>
> I have x = 39 which is the expected value 725 - 686 and I would like it.
> But that check fails (or better "succeeds") because of
>
> (gdb) p glyph->object
> $104 = XIL(0)
> (gdb) p glyph->charpos
> $105 = -1
> (gdb) p pt_old
> $106 = 725
> (gdb) p bpos_covered
> $109 = 0
>
> Then in
>
>       else if ((row->truncated_on_right_p && pt_old > bpos_max)
>              /* Zero-width characters produce no glyphs.  */
>              || (!empty_line_p
>                  && (row->reversed_p
>                      ? glyph_after > glyphs_end
>                      : glyph_after < glyphs_end)))
>       {
>         cursor = glyph_after;
>         x = -1;
>       }
>
> I have
>
> (gdb) p !empty_line_p
> $111 = 1
> (gdb) p glyph_after < glyphs_end
> $110 = 1
>
> x is set to -1 and in
>
>   if (x < 0)
>     {
>       struct glyph *g;
>
>       /* Need to compute x that corresponds to GLYPH.  */
>       for (g = row->glyphs[TEXT_AREA], x = row->x; g < glyph; g++)
>       {
>         if (g >= row->glyphs[TEXT_AREA] + row->used[TEXT_AREA])
>           emacs_abort ();
>         x += g->pixel_width;
>       }
>     }
>
> x eventually becomes 73 (759 - 686) which is what I see.  What could I
> do to make the check at the top succeed?
>
> martin

I'm not sure that would be sufficient.

The basic problem seems to go like below. Sorry if that gets a bit
complicated :-).

For ttys, I've introduced "frame-based" redisplay. The glyph producing
part of redisplay always works on windows, both on GUIs and ttys. On
GUIs, windows have their own glyph matrices which are independent of
each other. The frame has no glyph matrices. On ttys, frames _have_
glyph matrices that are allocated for them, and window glyph matrices
are sub-allocated from frame matrices. IOW when I look at a glyph G in a
window matrix on a tty frame, G is actually in the frame matrix.

I did that frame-based hocus pocus to minimize terminal output by being
able to determine if one can scroll part of the display. It's a long
story. The important part here is that a root frame's current matrix
_must_ contain what's displayed on the terminal for the whole update
part of redisplay on ttys to work.

Good.

Now let's assume we have a root frame R and a child C, and we are in the
update phase of redisplay.

If C is _not_ displayed, R's current matrix reflects R's contents; for
all windows on R, a window's current matrix corresponds to what is
currently displayed. I've used that fact to speed up redisplay. I didn't
remember set_cursor_from_row specifically, but it's one of those places,
as one can simply see from the fact that it looks at glyphs from R's
current matrix.

If C _is_ displayed, the combine_updates step in dispnew.c manipulates
R's current matrix to include C. This is needed because of what I said
above: R's current matrix must be what is displayed on the terminal. But
now, for all (x, y) on R displaying C, the glyphs now actually re copied
fro some window on C!. Or, said the other way 'round, the assumption
made that some window's current matrix can be used in cases like
set_cursor_from_row is no longer valid!

So, that's the problem, or what I think it is. A bit difficult to
describe :-/. It's sophisticated :-)