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

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

>  >> `temp-buffer-window-setup-hook' is run with *Help* current.  So
>  >> you won't have any problems discriminating this special case.
>  >
>  > How so?  (Not clear to me.)
> 
> You can test if the current buffer shows *Help* and change
> `w32-grab-focus-on-raise' only in that case.

Users should not be fiddling with hooks to work around this bug.
Especially hooks intended for more general features (temp buffers
in general).

>  >> I cannot possibly use a feature like `w32-grab-focus-on-raise'
>  >> whose semantics I neither understand nor can reenact in my
>  >> environment in the frame/window code of Emacs.
>  >
>  > Do you mean use for testing (this bug)?
> 
> I think we have established that "this bug" is not a bug.  So please
> refrain from calling it a bug.

We have not established any such thing.  It is a reproducible bug.
You even said that if the help window is not selected at the end of
`w-h-w' that is a bug.  And you found a way to ensure that it is
selected - why not just fix that?

Anyway, you did not respond to the question.  You say that you
cannot reenact the symptoms of the recipe in your environment (at
least I think that's what you were saying).  Why is that?  The
recipe is 100% reproducible in my environment (Win 7 64-bit).

>  > Or do you mean use in general, for your personal use of Emacs?
> 
> I don't understand what you mean here.

I asked for clarification of what you meant by saying that you
"cannot possibly use a feature like `w32-*'".  Did you mean use
it for your personal use?  Did you mean that you cannot test the
recipe using it?  What did you mean?  You answer that question
by asking me what I mean by asking what you mean...

>  > `w32*' is an Emacs option.  It is not something non-Emacs (e.g.,
>  > from MS Windows), and it is not something that I dreamed up.
>  > It, like `help-window-select', should work (for Emacs).  No?
> 
> `w32-grab-focus-on-raise' is a variable, not an option.

OK, yes; my bad.  But is the answer to the question to just be
pedantic (yes, I was wrong in thinking it was an option)?

My point was that it is an *Emacs* variable.  For *user
configuration*.  It is for users - it is not used in the Lisp
source code.  And GNU Emacs came up with it, not Microsoft.
It should work - for Emacs.

> IIUC it is a workaround that might work in some cases.

What basis do you have for supposing that it is intended only
as a workaround?

It is specifically mentioned in the Emacs manual (node `Windows
Misc'), and it has been documented there since Emacs 22 (maybe
even 21; dunno - it's not in the Emacs 20 manual, but the variable
is in Emacs 20).  That's the Emacs *user* manual, not the Elisp
manual.  We point this variable out to *end users*, on purpose.
This is not some internal, implementation thing.

It is too facile to just declare something that you might not
like or might not completely understand is only a "workaround
that might work in some cases" and not something that should
work generally.

> Apparently, it can fail in other cases.

You meant this case, this bug, or something else by "other cases"?
Attributing this bug to a single variable involved in the recipe
is a bit rich.  Especially since you found a simple fix for
`help-window-setup' that takes care of the bug.

> But we could change `help-window-setup' as follows:
>
>  > Would you please make this change to `help-window-setup'?
> 
> It would require further tuning.  In its current form it would
> focus a frame that already has focus which is a bad idea.

What further tuning?  Just not focusing a frame that is already
focused?  And why is focusing a focused frame a bad idea?  (Seems
like that operation should be idempotent.)

You are the expert in this area, not I.  I'm not presuming
anything.  But your response seems enigmatic, if not evasive.

Could you *please* fix `help-window-setup' the way you proposed
("we could change `help-window-setup' as follows..."), adding
whatever "further tuning" might be necessary?  Thank you.