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

From: Eli Zaretskii <[email-masked]>
Date: Sun, 26 Jan 2025 13:22:55 +0200

> Date: Sun, 26 Jan 2025 12:04:56 +0100
> Cc: [email-masked], [email-masked], [email-masked]
> From: martin rudalics <[email-masked]>
> 
>  >> 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.
> 
> Are you sure?  frame.h now has
> 
>    /* Nonzero if the frame is currently displayed; we check
>       it to see if we should bother updating the frame's contents. */
>    unsigned visible : 1;
> 
> where it formerly had
> 
>    /* Nonzero if the frame is currently displayed; we check
>       it to see if we should bother updating the frame's contents.
> 
>       On ttys and on Windows NT/9X, to avoid wasting effort updating
>       visible frames that are actually completely obscured by other
>       windows on the display, we bend the meaning of visible slightly:
>       if equal to 2, then the frame is obscured - we still consider
>       it to be "visible" as seen from lisp, but we don't bother
>       updating it.  */
>    unsigned visible : 2;

I just described what factually happens:

  emacs -Q -nw
  C-x 5 b RET
  M-: (frame-visible-p (next-frame)) RET
   => t