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

[martin rudalics <rudalics@gmx.at>]

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