bug#16479: 24.3.50; daemon freeze with tty menus

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: mvoteiza@udel.edu,  16479@debbugs.gnu.org
> Date: Mon, 20 Jan 2014 13:27:00 -0500
> 
> > 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?
> 
> Whatever we do, we should do it whether or not a tty menu is displayed.
> Switching frame inside a process filter is nasty but allowed.  So:
> - server.el should probably only change the selected frame temporarily and
>   revert it before returning from the process filter.

But I think server.el does this on purpose: if it didn't switch to the
new frame, you couldn't start typing into it after invoking
emacsclient, even when there's no menu displayed.  Wouldn't that be
confusing?

> - tty menus need to make sure they don't crash if a process filter
>   changes the selected frame.

That is easy.

>   But I think it's OK if they behave a bit strangely in that case.

Does the fact that you type into one frame and get response in another
count as "a bit strangely"?  Then we don't need to do anything except
to add some simple detection of the frame switch, see below.

>   IIUC with your recent change it doesn't crash any more, so it
>   might be good enough on this side.

The crash happened because the frame switch went unnoticed, and we
tried to use face IDs from one frame on another.  This no longer
happens, and I will add a simple code that will quit the menu when it
sees a frame switch.

Thanks.