GNU bug report logs -
#75056
31.0.50; tty-child-frames with server / multiple clients possible hangs
Previous Next
Full log
Message #104 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Len Trigg <lenbok <at> gmail.com> writes:
> On Fri, 24 Jan 2025 at 22:32, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
>
> I think the rest of the behavior is somehow multi-tty. We talked about
> that already. I don't think I'll tackle that, sorry.
>
> You mentioned in the earlier email about single-kboard mode being a
> limitation too big to address, but I'm confused as to why the child
> tty frame (minibuffer?) that the user had actually dismissed then
> magically reappears when the focus was moved to another terminal. Is
> it that the child tty frame needs to be fully destroyed upon
> dismissal? (Is that something posframe could do?) Could you please
> provide a description of what you think is actually happening?
I don't want to go down the rabbit hole of finding out what exactly is
happening, because that would mean I would begin to debug multi-tty,
which I wouldn't poke with a 2 meter stick after reading
admin/notes/multi-tty :-)
I have only one hint: the crash was because mini_frame in
redisplay_internal was invisible, and we updated it in
combined_update_for_frame. Updating an invisible frame logically makes
no sense, why is it invisible then? When that mini_frame is invisible,
is there another frame visible now that _should_ have been invisible
instead of mini_frame? If so, which one? And could it be that child
frames of that frame are now displayed? Possibly.
Question upon questions :-)
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.