bug#16479: 24.3.50; daemon freeze with tty menus

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 17 Jan 2014 20:54:46 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: mvoteiza@udel.edu, 16479@debbugs.gnu.org
> 
> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Cc: mvoteiza@udel.edu,  16479@debbugs.gnu.org
> > Date: Fri, 17 Jan 2014 11:16:26 -0500
> > 
> > So, ideally (recursion-depth) should be >0 when inside the tty menus,
> > and calling (top-level) should get us out of that tty menu.
> 
> I'll see what I can do.  Thanks.

I think I see the root cause.  It's in server-create-tty-frame, which
does:

    (set-frame-parameter frame 'display
                         (getenv-internal "DISPLAY" (process-get proc 'env)))
    (select-frame frame)

IOW, it switches to the newly created TTY frame from under the feet of
the menu input loop.  When read_menu_command returns, the selected
frame is different from what it was when the function was called.

It is easy enough to detect the frame switch, but the question is:
what to do when that happens?

This is complicated by the fact that the frame switch event is not
returned until some other event takes place.  Thus, while the new
frame is already selected, the old frame still has focus, until you
type something.  So to exit the vicious circle, you need to type
something into the old frame (which causes the new frame to react),
then switch to the new frame, and only then you are out of the woods.

I'm unsure how best to handle this mess.  Maybe avoid selecting the
new frame in server-create-tty-frame, if a TTY menu is currently being
displayed?