[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#16479: 24.3.50; daemon freeze with tty menus

From: Eli Zaretskii
Subject: bug#16479: 24.3.50; daemon freeze with tty menus
Date: Mon, 20 Jan 2014 19:48:45 +0200

> Date: Fri, 17 Jan 2014 20:54:46 +0200
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden, address@hidden
> > From: Stefan Monnier <address@hidden>
> > Cc: address@hidden,  address@hidden
> > 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

    (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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]