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

[martin rudalics]

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