bug#22068: 25.0.50; Delayed reaction to switching frames?

[Eli Zaretskii <eliz@gnu.org>]

> From: David Kastrup <dak@gnu.org>
> Cc: rudalics@gmx.at,  22068@debbugs.gnu.org
> Date: Thu, 03 Dec 2015 08:41:32 +0100
> 
> >   Optional fourth argument CAN-RETURN-SWITCH-FRAME non-nil means that
> >   this function will process a switch-frame event if the user switches
> >   frames before typing anything.  If the user switches frames in the
> >   middle of a key sequence, or at the start of the sequence but
> >   CAN-RETURN-SWITCH-FRAME is nil, then the event will be put off until
> >   after the current key sequence.
> 
> Well, the resulting user experience makes the impression of Emacs
> dragging its internals behind while it staggers on.  When the desktop
> environment already heeded and signaled a focus change, choosing a
> behavior where Emacs does not act on it is likely to break the visual
> feedback between what the user is doing and what Emacs is doing (how
> about changes of virtual desktops?).  The spurious keyboard half-echo of
> the frame switch event is just the cherry on top.

I agree.  The practical question is how to find some reasonable
solution here.

Is it possible for you to try to hack the functions involved in this,
such that read-key-sequence-vector is called with its 4th argument
non-nil, and see if the results are better or worse?  (I presume the
code in userlock.el will have to be changed to do something when this
event comes from read-char-choice, or something.)