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

[Drew Adams]

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

I won't argue about what it proves.  (I don't see how it proves
#2, but whatever.)  It might indicate only that `raise-frame' does
not necessarily do its "punctual" thing (raise the frame) exactly
when it is called, synchronously.  IOW, it might do that at some
later time, asynchronously.  Dunno.

My point about the interaction between `raise-frame' and
`with-help-window' was that the latter should try to ensure that
the window is selected when it *ends*, not at some earlier point.

But if `raise-frame' effectively does its thing *after*
`with-help-window' ends, even if called from within `w-h-w', then
that macro has no way to ensure selection after the actual effect
of `raise-frame'.

We can at least try to make sure that `w-h-w' selects the window
at the very end.

Of course, `w-h-w' should not affect selection for calls to
`raise-frame' (or other functions that select windows or focus)
that happen after it is done.  But if it can override any such
selections that take place within its scope/duration, that is good.

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

With the simple recipe I gave, that seems to fix things.  Thanks.
But:

1. The `temp-buffer-*-hook's are not only about showing *Help*.
   That workaround thus affects more than it should.

2. Users of `w32*' should not need to do that explicitly
   themselves.  Perhaps Emacs can do the equivalent, itself (but
   limited to *Help*, not affecting all temp buffer display).

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

Dunno where those are set in Windows (I could google), but thanks
for the info.  (I do want the `w32*' effect, though.)