[Top][All Lists]

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

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

From: Eli Zaretskii
Subject: bug#22068: 25.0.50; Delayed reaction to switching frames?
Date: Thu, 03 Dec 2015 09:52:51 +0200

> From: David Kastrup <address@hidden>
> Cc: address@hidden,  address@hidden
> 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.)

reply via email to

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