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

[Drew Adams]

> You have found out yourself that with your scenario the window
> is selected after `with-help-window' terminates.
> 
> You might as well complain that
> (progn
>    (switch-to-buffer "a")
>    (switch-to-buffer "b"))
> 
> does not show "a" in the selected window where according
> to its doc-string it should do that.

No relation.  I am perhaps not using "window selected"
correctly.  But as a user, how does it help that a window is
"selected" if I cannot type into it?  Of what use is such
selection?  You will no doubt say that it means that Lisp
can do things in that window, even if I cannot as a user.
But my point of view is as a user.

So you are free to call this bug report an enhancement
request, if you like.  And you can consider that it casts no
aspersions on `with-help-window' or `help-window-select',
but rather it asks that they together give the (user) input
focus to the help window (instead of only "selecting" it
for Lisp).

>  > You even said that if the help window is not selected
>  > at the end of `w-h-w' that is a bug.
> 
> Yes.  And we know meanwhile that it is selected.

It seems we are now nitpicking over the terms.  OK, it is
selected, for Lisp.  It does not have the input focus,
for a user.  The latter is what is important to me.

And honestly, isn't that the behavior you intended in
the first place?  Did you even consider the other-frame
case?  (I'm not saying you should have; I'm just asking.)

For the same-frame case, the behavior is the same for
selection and input focus.  So for that case (which I
imagine you had in mind, and tested) there is no bug
fix or enhancement needed.  The behavior is just what
a user wants and expects.

For the other-frame case the behavior is still broken
(inadequate), from my point of view.  I'm really only
asking that that case be fixed so that the user
experience is parallel to the same-frame case: the
*Help* window gets the focus, so that if a user hits,
say, `q' it disappears (as opposed to `q' being
inserted in the original buffer).

>  > And you found a way to ensure that it is
>  > selected - why not just fix that?
> 
> The window already gets selected.  But you want the
> window's frame get focus too.

Yes.  You understand correctly.

> The doc-string of `help-window-select' does not
> promise such a thing.

You wrote that doc string, I imagine.  I also imagine
that perhaps you did not consider the other-frame case.

In any case, I am requesting exactly that same behavior,
so that a user for the separate-frame use case has the
same experience as a user for the same-frame case: s?he
can interact directly and immediately with the *Help*
window using the keyboard.  If s?he hits `q' then it
should be the *Help* window and buffer that receive the
`q'.

> So this is not a fix but the implementation of a new
> feature.

If you like.  Or a missing part of the feature you
added.  The feature you added does not handle the
other-frame case.  And it should.  That's what this
bug report or enhancement request is for.

It's not about establishing in a court of law whether the
doc string's promise of the window being selected is in
fact fulfilled.  Nobody is suing anyone here.  And I'm
not criticizing the work you did in adding this feature.
I'm just saying that it will help people if it is extended
to the other-frame case as well.

It's about helping users and doing the right thing, not
justifying the status quo.

>  > 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.
> 
> There's nothing wrong with that.  But using this variable may have
> unwanted consequences for the user like the one we're talking about
> here.

Anything could have unwanted consequences.  Clearly, the
intention of those who provided `w32*' was to allow users
to choose to have `raise-frame' grab the focus.  Nothing more
or less than that.

>  > 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.
> 
> It does not work in general as you stated yourself.
> When the frame is created it gets focus and setting that
> variable doesn't help at all.

You are acting like a lawyer.  "Generally" does not necessarily
mean in every single case.  If there were a simple fix for the
MS Windows problem of it focusing new frames then Emacs would
have implemented that.  The inability to fix that problem does
not provide an excuse not to fix this problem.  Fix this
problem and you will have advanced the ability to use this
feature "in general".

>  > 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.
> 
> I proposed a solution to your problem but implementing it
> is less simple than I thought initially.

How so?  Can you discuss those problems?  Is adding that sexp
to `help-window-setup' worse than if the equivalent behavior
were done in `with-output-to-temp-buffer'?  IOW, if a user
fiddles with the temp-buffer hooks, is that workaround any
less problematic?

If so, maybe you can fix the problem by doing the equivalent
of a user fiddling with hooks that way.  IOW, maybe put that
code in the code that runs the hooks, instead of telling
users put it in the hooks.

I'm speculating, because you have said nothing about what
the problems are that make things "less simple than [you]
thought initially".

>  >> 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.)
> 
> It sends a request to the window manager because Emacs doesn't
> necessarily check whether the frame already has focus.  This
> might not harm on Windows but it might harm on other platforms.

Then either (1) do it and wait to see if problems are reported
for other platforms or (2) do it just for Windows (that's simple
enough to do).

IOW why make the ideal into the enemy of the good?  And why
assume that there will be problems on other platforms?

>  > 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.
> 
> I'll try to implement a feature that will focus the frame if
> it's different from the previous one.  Nothing more.

I appreciate your efforts on this (whether you think so or
not).  I am certain that if you try to improve the situation
for this use case you can do so, and without spoiling other
behavior, even if the fix might not be 100% perfect.  Please
give it a try.

Thx.