GNU bug report logs - #75056
31.0.50; tty-child-frames with server / multiple clients possible hangs

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: gerd.moellmann <at> gmail.com, lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
Subject: bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs
Date: Sun, 26 Jan 2025 13:22:55 +0200

> Date: Sun, 26 Jan 2025 12:04:56 +0100
> Cc: gerd.moellmann <at> gmail.com, lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  >> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.