Re: Implementing child frames on terminal

[Eli Zaretskii]

> From: Akib Azmain Turja <akib@disroot.org>
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org, ibluefocus@outlook.com
> Date: Tue, 12 Jul 2022 09:19:28 +0600
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I suggested to treat child frames on TTY as
> > special kinds of windows: if we do that, we "just" need to support
> > windows whose glyph matrix partially overlaps those of the other
> > windows, and make sure we update the glyph matrices of the child
> > frame's windows _after_ we are done with all the windows of the parent
> > frame.  This way, the frame glyph matrix that is eventually used to
> > update what's on the glass will correctly reflect what should be on
> > the screen.
> 
> Your idea is good, but until the child frame crosses the edges of it's
> parent.  Then it'll cause a segmentation fault (the best case) or
> continue without any symptom and corrupt your files or something else
> silently (the worst case).

I suspect there's a misunderstanding here: when I said "frame glyph
matrix", I meant that in the sense it is used in dispnew.c -- the
glyph matrix describing the frame that is the parent of all the other
windows and child frames.  That frame cannot possibly be "crossed",
because it by definition has the full dimensions of the TTY display.

> And the final question, what should we do when the child frame crosses
> it's parent's edges, but doesn't cross the display?  Should we clip it
> (like most window systems) [1] or not (like NS) [2]?

The former, I think.  But maybe we could make it customizable.  The
difference from the code POV is not that big.