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

Previous Next

Full log

Message #17 received at 22068 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 22068 <at> debbugs.gnu.org, dak <at> gnu.org
Subject: Re: bug#22068: 25.0.50; Delayed reaction to switching frames?
Date: Wed, 02 Dec 2015 15:49:11 +0200

> Date: Wed, 02 Dec 2015 11:05:37 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> Cc: 22068 <at> debbugs.gnu.org
> 
>  > No, doesn't help.  I mean, when moving the mouse over, it still takes
>  > half a second for the frame highlighting to change, indicating the
>  > changed focus from the view of the window manager (I guess).  So I
>  > cannot vouch that the window manager isn't involved in the delayed frame
>  > switch.
> 
> I just tried with xfwm4.  Here a focus_delay of 185 (ms I presume)
> behaves as expected while a delay of 1850 shows the behavior you
> describe.
> 
>  > And indeed: the strange switch-frame- keyboard echo
> 
> ... which happens also when the prompt appears in the frame the mouse
> moved to and I now move the mouse back to the other one - I always
> wondered how to get rid of them ...
> 
>  > as a reply to the
>  > "changed on disk; really edit the buffer?" prompt in connection with the
>  > minibuffer (and actual keyboard focus) staying in the old frame in spite
>  > of the mouse pointer and the focus highlighting having moved over: that
>  > remains the same even if I keep the apparently perceived order of
>  > events: I cannot switch frames in reply to the "really edit the buffer"
>  > prompt.
> 
> All this seems very hardcoded in choose_minibuf_frame.

Could this have something to do with the fact that read-char-choice
calls read-key-sequence-vector with the CAN-RETURN-SWITCH-FRAME
argument nil?

Previous Next

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