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

[martin rudalics]

> The bug is apparently caused by `w32-grab-focus-on-raise' = nil.
> That should only have the effect of not causing `raise-frame' to
> focus the frame.  It should not prevent `help-window-select' (or
> anything else) from selecting the window.

What makes you sure that it does prevent `help-window-select' from
selecting the window?

> The effect should, because of `help-window-select' = t, be that
> the *Help* window is selected.  Selection should not depend on
> whether `raise-frame' happens to also select/focus.

Then you know more than me.  `w32-grab-focus-on-raise', if nil, triggers
a DeferWindowPos type chain of events, see

http://msdn.microsoft.com/en-us/library/windows/desktop/ms632681%28v=vs.85%29.aspx

which is beyond my comprehension.

> ;; This somehow causes the window/frame NOT to be selected.
> ;; If non-nil then there is no problem.
> (setq w32-grab-focus-on-raise  nil)

Then leave it non-nil.

> Note that the doc string of `w32-grab-focus-on-raise'
> specifically does not say that a value of nil means that
> `raise-frame' takes the focus away (unfocuses).  It says
> only that a value of t means that `raise-frame' focuses
> the frame.
>
> Since nothing is said for nil, the presumption should be
> that a nil value has no particular effect on focus, i.e.,
> that it neither "grabs input focus", as does t, nor
> removes focus.

If you understand what it does, provide a suitable doc-string.

> And all of this code is anyway inside `with-help-window'
> because of `C-h v'.  So even if the bug were that
> `raise-frame' removed the focus (unlike what the
> `w-g-f-o-r' doc string says), `help-window-select'
> should anyway ensure that *Help* is focused in the end.

If you told us how `with-help-window' should deal with asynchronous
frame raise/focus events, we could try to find a solution.

> ----------------- What I said before ---------------
>> Found it, I guess.
>>
>> In addition to non-nil pop-up-frames and the other code sent
>> previously, do this: (setq w32-grab-focus-on-raise  nil)
>>
>> Then, as I described, when the *Help* frame already exists it is not
>> selected by C-h v etc.
>>
>> Now IIUC, that variable, `w32-grab-focus-on-raise', should only
>> stop Windows from having `raise-frame' always focus the frame.
>> That really is (should be) something different from this
>> (`help-window-select').
>>
>> IOW, I do not want `raise-frame' to automatically focus the
>> frame for input each time.  But I might want `help-window-select'
>> to select the *Help* frame.  Make sense?

I can only repeat myself: I don't understand what is at work here and
how this is supposed to work.  `help-window-select' simply selects the
window if certain conditions are met.  How selection is implemented and
what consequences it has is platform dependent and beyond its control.

martin