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: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: rudalics <at> gmx.at, 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 11:13:02 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: rudalics <at> gmx.at,  lenbok <at> gmail.com,  75056 <at> debbugs.gnu.org
> Date: Sun, 26 Jan 2025 09:55:48 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> (Where "top" in that case is not a z-order thing, but all root frames on
> >> a tty are just part of the frame lists in parallel to each other, like
> >> before child frames. AFAIR, something in tty_display_info
> >> says who owns the terminal.)
> >
> > So it is still true that a frame other than the top frame returns t
> > from frame-visible-p, right?  Here's the recipe:
> >
> >   emacs -Q -nw
> >   C-x 5 b RET
> >   M-: (frame-visible-p (next-frame)) RET
> >    => t
> >
> > This is different from GUI frames, in that z-order is not considered
> > on TTYs.
> 
> That looks like a bug to me. I think it should return nil. (Although I'm
> never 100% sure with the frame code.) Opinions?

It's the way Emacs behaved until now with TTY frames.  We can decide
we want to change that in Emacs 31, of course, but then we need to
update the documentation accordingly.  E.g., see "Raising and
Lowering" in the ELisp manual, and the functions mentioned there.

Previous Next

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