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

From: Eli Zaretskii <[email-masked]>
Date: Sun, 26 Jan 2025 10:11:50 +0200

> From: Gerd Möllmann <[email-masked]>
> Cc: [email-masked],  [email-masked]
> Date: Sun, 26 Jan 2025 08:50:14 +0100
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> > What happens in this case is that F2 cannot be communicated with:
> > typing anything there gets no response, until we exit the minibuffer
> > on F1.  Then everything you typed on F2 gets processed.
> >
> >> Find in the code what actually happens when switching from F1 to F2 and
> >> compare that with admin/notes/multi-tty has to say about that. Does that
> >> document say something about what we've seen the code doing? Open issues
> >> maybe? Or general considerations?
> >
> > What the code does when Emacs enters a minibuffer is switch to a
> > "single-keyboard mode", whereby it only processes keyboard input from
> > the frame which entered the minibuffer.  This is because Emacs has
> > only one input queue.
> 
> I would perhaps check how that switching to single-kboard is done. That
> is, which C functions do that, what does do_switch_frame do and so on.

See temporarily_switch_to_single_kboard in keyboard.c.

> And why does the mini_frame in redisplay_internal end up invisible? Is
> F1 invisible now, and if so why?

I don't think I follow: what mini_frame are you talking about?  AFAIU,
the scenario described in

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75056#92

said that the child frame (which is the minibuffer frame in this
scenario, right?) was dismissed, so the fact that it becomes invisible
is explained by that?  Or maybe I didn't understand what was described
there, since, unfortunately, this uses Corfu without telling enough
about what's going on for people who are unfamiliar with Corfu.
AFAIU, the scenario described there was talking about child frames,
and the problem was that the child frame got displayed although it was
dismissed before.