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

From: Eli Zaretskii <[email-masked]>
Date: Sun, 26 Jan 2025 11:10:03 +0200

> Date: Sun, 26 Jan 2025 09:53:19 +0100
> Cc: [email-masked], [email-masked]
> From: martin rudalics <[email-masked]>
> 
>  >> 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.

OK, but then this is only relevant to child frames on a TTY.

>  >> 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?

See tty-top-frame.

>  >> 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?

No, we still ignore that on TTYs, for non-child frames.  See my other
message.