bug#19012: 25.0.50; `help-window-select'

[martin rudalics]

>>   > I too see the message "#<window 6 on *Help*>".
>>   >
>>   > However, if I type text it is inserted in buffer *scratch*.
>>   > And the *Help* frame border indicates that it is not the
>>   > current/focused/selected frame.
>>   >
>>   > So apparently the frame is not focused, even if the window is
>>   > selected.  HTH.
>>
>> What does evaluating (selected-window) give when the *Help* frame is
>> raised while the *scratch* frame is focused?
>
> `M-: (selected-window)' at that point shows: #<window 3 on *scratch*>

Together this proves two things:

(1) `with-help-window' correctly selects the *Help* window.

(2) `raise-frame' is far from "punctual" (takes place at a moment in
    time) as you claimed earlier.

You can try the following: In `temp-buffer-window-setup-hook' set
`w32-grab-focus-on-raise' to t.  In `temp-buffer-window-show-hook' set
it back to nil.

Meanwhile I seem to understand why I can't see the behavior you describe
on my Windows XP.  I have both "Activation follows mouse" and "Autoraise
when activating" set.  So apparently when the second frame is raised my
mouse moves there and focuses the frame.  This means that the rigmarole
done by `w32-grab-focus-on-raise' nil has no effect here at all.

martin