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

From: Gerd Möllmann <[email-masked]>
Date: Sun, 26 Jan 2025 10:24:31 +0100

Eli Zaretskii <[email-masked]> writes:

>> From: Gerd Möllmann <[email-masked]>
>> Cc: [email-masked],  [email-masked],  [email-masked]
>> Date: Sun, 26 Jan 2025 09:55:48 +0100
>> 
>> Eli Zaretskii <[email-masked]> 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.