[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#19012: 25.0.50; `help-window-select'
From: |
martin rudalics |
Subject: |
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
- bug#19012: 25.0.50; `help-window-select', (continued)
- bug#19012: 25.0.50; `help-window-select', martin rudalics, 2014/11/11
- bug#19012: 25.0.50; `help-window-select', Drew Adams, 2014/11/11
- bug#19012: 25.0.50; `help-window-select', martin rudalics, 2014/11/11
- bug#19012: 25.0.50; `help-window-select', Drew Adams, 2014/11/11
- bug#19012: 25.0.50; `help-window-select', Drew Adams, 2014/11/11
- bug#19012: 25.0.50; `help-window-select', Drew Adams, 2014/11/13
- bug#19012: 25.0.50; `help-window-select', martin rudalics, 2014/11/13
- bug#19012: 25.0.50; `help-window-select', Drew Adams, 2014/11/13
- bug#19012: 25.0.50; `help-window-select', martin rudalics, 2014/11/13
- bug#19012: 25.0.50; `help-window-select', Drew Adams, 2014/11/13
- bug#19012: 25.0.50; `help-window-select',
martin rudalics <=
- bug#19012: 25.0.50; `help-window-select', Drew Adams, 2014/11/13
- bug#19012: 25.0.50; `help-window-select', martin rudalics, 2014/11/14
- bug#19012: 25.0.50; `help-window-select', Drew Adams, 2014/11/14
- bug#19012: 25.0.50; `help-window-select', martin rudalics, 2014/11/14
- bug#19012: 25.0.50; `help-window-select', Drew Adams, 2014/11/14
- bug#19012: 25.0.50; `help-window-select', martin rudalics, 2014/11/14
- bug#19012: 25.0.50; `help-window-select', Drew Adams, 2014/11/14
- bug#19012: 25.0.50; `help-window-select', martin rudalics, 2014/11/14
- bug#19012: 25.0.50; `help-window-select', Drew Adams, 2014/11/14
- bug#19012: 25.0.50; `help-window-select', martin rudalics, 2014/11/14