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

[David Kastrup <dak@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  22068@debbugs.gnu.org
>> Date: Wed, 02 Dec 2015 20:58:10 +0100
>> 
>> >> When I call the function it does call, that call does not return if it
>> >> gets switch-frame events.  IOW, the function that asks the question
>> >> doesn't know the frame was switched, and cannot do what David probably
>> >> wants: switch frame and reissue the question.
>> >
>> > OK.  But how can we get rid of that "switch-frame-" echo at least?
>> 
>> If the function is not supposed to return switch-frame events, why
>> doesn't it _act_ on them then?
>
> According to documentation, it does act on them, only later:
>
>   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.

-- 
David Kastrup