GNU bug report logs - #19012
25.0.50; `help-window-select'

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>, 19012 <at> debbugs.gnu.org
Subject: bug#19012: 25.0.50; `help-window-select'
Date: Sun, 16 Nov 2014 18:36:13 +0100

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.