Re: Q: child frames on ttys

[martin rudalics]

> So, this seems to work, at least in principle. Where in principle means
> I didn't try much yet, but it looks like I can at least display
> overlapping child frames.

The screenshot looks good.  The question is how much resources it takes
to turn the visibility of child frames on and off.  I conjecture that
restoring the original frame glyph matrix could/should be even cheaper
than handling the corresponding expose events on graphic frames.

I wonder whether you should invariably show truncation/continuation
columns on child frames and give them a same background as line numbers,
title bars and modelines to make the child frame stand out more against
the overlapped frame.  At least optionally.

> I have a question regarding the child frame feature in general though.
>
> As I said before, I want to use them for Corfu and Posframe, the latter
> with Vertico and Transient. But the child frame feature looks like
> something much more general, more like a general MDI feature, as opposed
> to SDI. And my question is: Is that actually used somewhere? In some
> package, or in Emacs itself? If it is, I'd be grateful for a pointer.

Initially, I wrote the child frame code because I found the necessary
APIs for Windows and X and planned to use them for tooltips.  Later I
found out that they are not really useful for that purpose because on
graphic displays tooltips are often displayed outside the parent frame
while child frames are clipped.  Moreover, tooltips usually disappear
when the user interacts in some way and the major advantage of child
frames - namely that they move together with their parent - gets lost in
practice.  I even spent some time on 'window-largest-empty-rectangle' to
avoid that tooltips hide any normal text.  Currently, I'm still using
normal frames for tooltips while I'm using child frames mostly for
displaying the minibuffer.

Child frames can be used to overcome the classic restriction that Emacs
windows are "tiled".  'display-buffer-in-child-frame' conceptually
provides that feature.  But I don't see why that would need any special
treatment on TTYs.  Why do you think that MDI vs SDI would impact the
design of child frames on TTYs?

> (Background is of course that I'm trying to assess how much work is
> ahead, and if I want to do it :-).

I suppose that visibility and restacking of child frames and size
changes of child frames and their ancestors are the corner issues.  Once
these have been resolved, the code should be pushed and you should wait
for user feedback.

Many thanks for lifting the "Note that child frames are meaningful on
graphical terminals only." restriction, martin