Re: Implementing child frames on terminal

[Eli Zaretskii]

> From: Akib Azmain Turja <akib@disroot.org>
> Cc: luangruo@yahoo.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org,
>  ibluefocus@outlook.com
> Date: Tue, 12 Jul 2022 20:21:02 +0600
> 
> >> Really?  It looks like it would require to modify whole redisplay logic
> >> to make sure whether a glyph is inside edges and write to it only if it
> >> is.
> >
> > Actually, the current redisplay code does this all the time: that's
> > how we know when to continue or truncate a too-long line, or where to
> > wrap a long line under visual-line-mode.
> >
> 
> But this problem is different than that.  In your too-long line case,
> redisplay code checks whether a glyph is inside the window.  But for
> child frames, it needs to check whether a glyph is inside the parent
> frame (i.e. safe to write to), write it if it is and always assume
> that it was written successfully.
> 
> For example, if we have a 30 chars wide child frames displaying a 40
> chars wide line and the child frame's left edge is 20 char away from
> it's parent right edge, the redisplay code has to write the first 20
> chars to the glyph matrix and don't write the next 10 chars, but still
> think that they were written, and finally truncate the last 10 chars or
> wrap it depending on the value of "truncate-lines".

The way redisplay of a window works, it starts by determining how wide
can each screen line be before it overflows the right edge of the
window.  The result of this is the member of 'struct it' called
'last_visible_x'.  It is computed once (see init_iterator), and then
used everywhere when we need to decide whether there's place in the
screen line for one more glyph.

So to support the above, we'd just need to modify the calculation of
last_visible_x in init_iterator such that it takes into consideration
the edge of the parent frame.  And that shouldn't be hard, given that
we know the offset of the child frame from its parent frame.