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

[David Kastrup <dak@gnu.org>]

martin rudalics <rudalics@gmx.at> writes:

>> I cannot absolutely vouch that the window manager setting "sloppy"
>> (which can be selected with gnome-tweak-tool) is innocent of the
>> problem.  But there are no delay settings to select.
>
> Did you try with "mouse" or whatever you have to remove focus from a
> frame when the mouse leaves it?
>
> Not that I think it would change anything ...

Well, it would make the timing of the focus change slightly earlier.
Not likely early enough.  Let me try.

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.

And indeed: the strange switch-frame- keyboard echo 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.

If I answer (with focus in the old frame and mouse pointer in the new
frame) "n" to that question, the error message "xxx: changed on disk"
then appears in the new frame, and so does the focus.

So while the delayed switch may or may not be Emacs' fault, the annoying
effect of not reacting to the frame change as long as the prompt is
active does not depend on the timing of the switch.

-- 
David Kastrup