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

[martin rudalics]

> 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.

> 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.

I'm afraid lots of this has been special coded to work for stand alone
minibuffer frames.  These have to pop up and keep focus till the reply
arrives.

martin