GNU bug report logs - #22068
25.0.50; Delayed reaction to switching frames?

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: David Kastrup <dak <at> gnu.org>
Cc: rudalics <at> gmx.at, 22068 <at> debbugs.gnu.org
Subject: bug#22068: 25.0.50; Delayed reaction to switching frames?
Date: Thu, 03 Dec 2015 09:52:51 +0200

> From: David Kastrup <dak <at> gnu.org>
> Cc: rudalics <at> gmx.at,  22068 <at> 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.)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.