GNU bug report logs -
#75056
31.0.50; tty-child-frames with server / multiple clients possible hangs
Previous Next
Full log
Message #188 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> 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.
I'd vote for changing this. I find things easier to understand when
there are as few as possible exceptions.
BTW, what does (frame-visible-p F) say, when F is a frame on another
terminal? Out of interest. I would find it natural if that returned t
if F is the top frame of that terminal, and nil if not.
This bug report was last modified 110 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.