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: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 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: Tue, 28 Jan 2025 13:30:55 +0100

martin rudalics <rudalics <at> gmx.at> writes:

>>> The root_frame of the old top frame is the old top frame itself.  Or am
>>> I missing something?
>>
>> Maybe. Make a child with M-l, then in the child
>>
>>    (frame-parent (tty-top-frame)
>>    => F1
>>
>> It's 1:1 the display info's top_frame. IOW, I left the setting of
>> top_frame as is was before, only that there are now child frames to
>> which it gets set.
>
> What I meant was that currently with
>
> (setq F1 (selected-frame))
> (setq F2 (make-frame))
> (next-frame)
> (frame-visible-p F1)
>
> the last form evaluates to t.  But if we change 'frame-visible-p' to not
> always return t if the argument frame is a tty frame, the above will
> give nil IIUC.  And that's not what happens on a GUI.
>
>>> I think we should use the metaphor of a top frame on a tty as that of a
>>> maximized frame on a GUI.  Such a frame hides all other normal frames on
>>> that workspace but does not render them invisible or iconified (I ignore
>>> z-order and groups here).
>>
>> That's not so in the current code. And why should it be so complicated?
>> Either I can see a frame or not.
>
> Be aware that it will change the current behavior for top frames and
> make tty frame handling different from what it is on a GUI.
>
>> It's much easier for me to think about if this second concept of being
>> obscured does not exist. And it's easier in redisplay: If it's visible
>> display it, otherwise don't.
>
> The question is not whether to display it if it's not visible.  The
> question is whether Lisp code should consider it as visible.
>

Okay, understood. Changing the C code would be quite a challenge anyway
:-). It took me at least 10x the time to get to what is there now
frame-wise, so to speak, compared to what I needed to add to redisplay.

Will you continue to work on this?

I'm asking because I'm considering to phase down my involvement in
Emacs, at least for some time. I'll continue to be available per mail,
of course, but I don't plan to commit changes.

Previous Next

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