bug#16479: 24.3.50; daemon freeze with tty menus

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 20 Jan 2014 23:17:03 +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: Mon, 20 Jan 2014 15:28:42 -0500
> > 
> > >> 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?
> > 
> > I'm not sure it's the case.  The reason is that you're talking about
> > a change of focus whereas the code changed the selected frame.  The two
> > are related but the relation is very murky.
> > 
> > > Does the fact that you type into one frame and get response in another
> > > count as "a bit strangely"?
> > 
> > Yes.
> 
> OK, then I know what to do.  Thanks.

Or maybe not.  I did what I thought was needed (see bzr r116153), but
there's still a problem with restoring the original value of
overriding-terminal-local-map after popping down the menu.  E.g., in
this scenario:

  emacs -Q -nw
  M-x server-start
  F10

then in another terminal:

  emacsclient -t

This pops down the menu, but the value of
overriding-terminal-local-map in the original frame is not restored,
so, for example, any cursor motion command signals an error because it
tries to invoke tty-menu commands.

What am I not doing correctly here?  TIA.