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

[martin rudalics]

>> So you want `raise-frame' to not select the frame and `with-help-
>> window' select the frame?  Any preferences who should win that game?
>
> There is no game.
>
> 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.

> `raise-frame' is punctual.

I have no idea what you mean here.

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

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

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

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

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

> 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.  There is
absolutely nothing `with-help-window' or any Elisp code can do there.

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

martin