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

Previous Next

Package: emacs;

Reported by: Drew Adams <drew.adams <at> oracle.com>

Date: Mon, 10 Nov 2014 16:43:03 UTC

Severity: minor

Found in version 25.0.50

Done: martin rudalics <rudalics <at> gmx.at>

Bug is archived. No further changes may be made.

Full log


Message #62 received at 19012 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>, 19012 <at> debbugs.gnu.org
Subject: Re: bug#19012: 25.0.50; `help-window-select'
Date: Thu, 13 Nov 2014 19:47:49 +0100
>> So you want `raise-frame' to not select the frame and `with-help-
>> window' select the frame?  Any preferences who should win that game?
>
> There is no game.
>
> 1. `raise-frame' should not focus the frame (or unfocus it), unless
> `w32-grab-focus-on-raise' is non-nil (or unless there is also some
> other, similar option that makes `raise-frame' grab the focus).
> And as far as I can tell, that is the case: it does not.

IIUC the default behavior on Windows is that when you raise a frame,
that frame gets focus as well.  So if you set `w32-grab-focus-on-raise'
to nil, Emacs has to explicitly tell Windows to unfocus the frame.

> But even if it did, that should be irrelevant to what
> `help-select-window' does (*this* bug).

What is "*this* bug"?  You attribute a behavior you observe to a
variable that does not and cannot control that behavior.

> `raise-frame' is punctual.

I have no idea what you mean here.

> The scope and effect of `help-select-window' are controlled by
> `with-help-window' (according to you, whom I believe; I'm no expert
> on that, and that is not documented, AFAICT).

Scope and effect of `help-window-select' end where `with-help-window'
exits.

> 2. `help-window-select' = `t' (within `with-help-window', at least)
> should select the help window.  (Likewise, for a value of `other',
> unless the selected window is alone on the help-window's frame.)
>
> This is all specified by the doc (except the connection between
> `help-window-select' and `with-help-window').  And there is no
> contradiction between #1 and #2.  `help-window-select' has nothing
> to do with `w32-grab-focus-on-raise' and nothing to do with
> `raise-frame' (at least according to its spec/doc). And it *should*
> have nothing to do with them.

If `help-window-select' is t, `with-help-window' selects the frame
unconditionally.

> Whether `raise-frame' focuses the frame or not should be irrelevant
> to the behavior imposed by `help-window-select'.  It is (according
> to you) `with-help-window' that controls the scope of the effect
> of `help-window-select'.  It is `with-help-window' that should
> ensure that `help-window-select' has the effect it claims to have
> when `with-help-window' is finished.

Doesn't it?

>>   > It is you who stated what I should expect from the behavior
>>   > of `help-select-window', provided the context is
>>   > `with-help-window'.  *You* stated that it is a bug if the
>>   > window is not selected.
>>
>> So far you did not provide any evidence that the window is not
>> selected.
>
> Sure I did.

You didn't even care to go through this with a debugger.  What kind of
evidence is that?

> I said that it does not have the input focus.  Type
> text and it goes to the window where you hit `C-h v'.  What's more,
> the frame border highlighting shows that the frame is not focused.

This does not contradict that `with-help-window' selected the window.

> You seem to be in denial, for some reason.  Believe me, the
> *Help*-selecting effect of non-nil `help-select-window' disappears
> if `w32-grab-focus-on-raise' is nil.

I never doubted that.  But it seems to me that you don't want to care
how a nil value for `w32-grab-focus-on-raise' gets processed.  There is
absolutely nothing `with-help-window' or any Elisp code can do there.

> It should not disappear.  `w32-grab-focus-on-raise' should affect
> only `raise-frame'.  And `help-window-select' & `with-help-window'
> should not be affected by whether there is a call to `raise-frame'
> or what such a call might do wrt frame focus.

You can't have both - select the frame and unfocus it.

martin




This bug report was last modified 10 years and 155 days ago.

Previous Next


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