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

[Drew Adams <drew.adams@oracle.com>]

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

I did not say that it prevents that, and certainly not that I am
sure that it prevents that.  Please read what I actually said.

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

Again, I think you are not reading well what I wrote.  I claim
nothing about what is actually happening in the code.  I reported
symptoms, and I stated that there should not be such a dependency.
I did not say that there is any such dependency.

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

If that article is beyond your comprehension then it is most
likely beyond mine as well.

But I mentioned an *Emacs* option.  Emacs decides the behavior
of that option.  I have said nothing about the Emacs
implementation.  I care about the resulting behavior, not how
the bug is fixed.

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

I've been clear that (a) I do not want `raise-frame' to focus
frames, and that (b) whether I, as one user, want that behavior
or not, the behavior of that option should not affect whether
`help-window-select' works.

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

Again, you are misreading, it seems.  (a) I did not say that I
understand what it actually does (beyond the bugged symptoms I
reported).  (b) I made it clear that the bug reported is about
the behavior, not a 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.

It is you who stated what I should expect from the behavior
of `help-select-window', provided the context is
`with-help-window'.  *You* stated that it is a bug if the
window is not selected.

I have nothing to say about the implementation of
`with-help-window'.  I reported a bug in behavior.

It seems clear from your "if-you-know-so-much-then-fix-it"
over and over that you do not want to work on a fix for this.
That's your right, of course.  I reported the bug.  You
clarified some things about it.  Maybe someday Someone (TM)
will try to fix it.  Maybe not.

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

Fair enough.  I have no idea either what combination of code
causes the bugged behavior.  One place (for Someone (TM)) to
look might be (just a guess) the code that implements and uses
`w32-grab-focus-on-raise'.