Subject: bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs

From: martin rudalics <[email-masked]>
Date: Sun, 26 Jan 2025 09:53:19 +0100

>> Martin mentioned in passing that he thinks iconifying frames on ttys
 >> should perhaps do something. So it's maybe a "not yet".
 >
 > What could that "something" possibly be?  Martin?

See the option 'iconify-child-frame'.  We have to explain its semantics
for tty child frames: The two obvious choices are to either do nothing
or make the child frame invisible.

 >> Yes. C-x 5 2 can make a new root frame, and only one is visible on
 >> the display.
 >
 > So only the top root frame now returns visible = t?

What is the "top root frame"?  Have we defined it somewhere?

 >> raise-frame is make-frame-visible + changing z-order, make-frame-visible
 >> and make-frame-invisible change the "visible" flag. (Just notices
 >> make-frame-visible talks about "X window", hm.).
 >>
 >> Did you mean these doc strings should be changed, too, or did you mean
 >> something else?
 >
 > I wanted first to understand what happens with this on TTY frames.
 > Then we'd need to update the doc strings and also the manuals.

I still wonder what happened to the "when one frame completely obscures
another" visibility state issue.  Has that vanished?  IIUC it would make
a child frame (and possible even a root frame) practically invisible
when no part of its drawn by redisplay.  On a GUI the WM would decide
that and we don't have to care (IIRC we did care on Windows in the past
- at least when debugging).

martin