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

[martin rudalics <rudalics@gmx.at>]

 > 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