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

[Drew Adams]

>  > 1. `raise-frame' should not focus the frame (or unfocus it),
>  > unless `w32-grab-focus-on-raise' is non-nil (or unless there is also
>  > some other, similar option that makes `raise-frame' grab the focus).
>  > And as far as I can tell, that is the case: it does not.
> 
> IIUC the default behavior on Windows is that when you raise a frame,
> that frame gets focus as well.  So if you set `w32-grab-focus-on-
> raise' to nil, Emacs has to explicitly tell Windows to unfocus the frame.
> 
>  > But even if it did, that should be irrelevant to what
>  > `help-select-window' does (*this* bug).
> 
> What is "*this* bug"?  You attribute a behavior you observe to a
> variable that does not and cannot control that behavior.

Bug 19012.  As you admitted, if `help-window-select' is t, it is a bug
if `with-help-window' exits with the window not selected.
 
>  > `raise-frame' is punctual.
> 
> I have no idea what you mean here.

It takes place at a moment in time.  `with-help-window' has an effect
for a duration/scope.  `with-help-window', with `help-window-select'
= t, should ensure that the window is selected when it is finished.

>  > The scope and effect of `help-select-window' are controlled by
>  > `with-help-window' (according to you, whom I believe; I'm no
>  > expert on that, and that is not documented, AFAICT).
> 
> Scope and effect of `help-window-select' end where `with-help-
> window' exits.

Precisely.  And not before.

If Emacs is fixed so that `with-help-window' ensures that the window
is selected when it exits (with non-nil `help-window-select') then
this bug (#19012) can be closed.

>  > 2. `help-window-select' = `t' (within `with-help-window', at
>  > least) should select the help window.  (Likewise, for a value of
>  > `other', unless the selected window is alone on the help-window's
>  > frame.)
>  >
>  > This is all specified by the doc (except the connection between
>  > `help-window-select' and `with-help-window').  And there is no
>  > contradiction between #1 and #2.  `help-window-select' has
> nothing
>  > to do with `w32-grab-focus-on-raise' and nothing to do with
>  > `raise-frame' (at least according to its spec/doc). And it
> *should*
>  > have nothing to do with them.
> 
> If `help-window-select' is t, `with-help-window' selects the frame
> unconditionally.

Great.  Does it ensure that it is selected when it is finished?
It seems that that is not the case yet.  AFAICT (from the info you've
provided), that is the cause of the bugged behavior.

>  > Whether `raise-frame' focuses the frame or not should be
>  > irrelevant to the behavior imposed by `help-window-select'.
>  > It is (according to you) `with-help-window' that controls the scope
>  > of the effect of `help-window-select'.  It is `with-help-window'
>  > that should ensure that `help-window-select' has the effect it
>  > claims to have when `with-help-window' is finished.
> 
> Doesn't it?

Apparently not.  The window is not selected/focused.  (And the
`raise-frame' is called within `with-help-window', not after
`with-help-window' is finished.

>  >>   > 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.
>  >>
>  >> So far you did not provide any evidence that the window is not
>  >> selected.
>  >
>  > Sure I did.
> 
> You didn't even care to go through this with a debugger.  What kind
> of evidence is that?

Dunno what that means.  If you have some recipe you'd like me to
follow, I'll see if I can try it.

>  > I said that it does not have the input focus.  Type
>  > text and it goes to the window where you hit `C-h v'.  What's
>  > more, the frame border highlighting shows that the frame is not
>  > focused.
> 
> This does not contradict that `with-help-window' selected the
> window.

I think it contradicts the expectation that `with-help-window'
ensures that the window is selected when it finishes.  After it
finishes, it of course has no more responsibility wrt whether it
is selected.

>  > You seem to be in denial, for some reason.  Believe me, the
>  > *Help*-selecting effect of non-nil `help-select-window'
>  > disappears if `w32-grab-focus-on-raise' is nil.
> 
> I never doubted that.  But it seems to me that you don't want to
> care how a nil value for `w32-grab-focus-on-raise' gets processed.

Yes, I don't want to get involved with the implementation or
trying to fix the problem.  I am willing to report the problem
and try to obtain more info about symptoms.

> There is absolutely nothing `with-help-window' or any Elisp code
> can do there.

I never said there was.  Perhaps that is the communication problem
here.  I never said that you are responsible for the bug or for
fixing it.  And I never said that the bug is due to Elisp code.
(In fact, since I discovered that it is nil `w32-*' that leads to
the bug, I've been supposing that the problem involves C code.)

>  > It should not disappear.  `w32-grab-focus-on-raise' should affect
>  > only `raise-frame'.  And `help-window-select' & `with-help-
>  > window' should not be affected by whether there is a call to
>  > `raise-frame' or what such a call might do wrt frame focus.
> 
> You can't have both - select the frame and unfocus it.

I'm not asking to unfocus the frame.  I'm asking that
`with-help-window' ensure that, when it exits, the window is
selected and the frame focused.  And that, regardless of whether
some code within its scope happens to focus some other frame
at some point.