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

[martin rudalics <rudalics@gmx.at>]

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

I asked you twice to not call this a bug.  This is the last time I ask
you to drop it.

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

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

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

 > 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.  The doc-string of `help-window-select' does not promise such
a thing.

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

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

I mean that code in help.el or window.el does not act specially with
respect to the value of a variable like `w32-grab-focus-on-raise'.

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

The way this variable affects the execution of `raise-frame'.  You can
convince me of the contrary if you tell me how it does that.

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

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

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

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

martin