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: Thu, 13 Nov 2014 08:44:50 +0100

> The bug is apparently caused by `w32-grab-focus-on-raise' = nil.
> That should only have the effect of not causing `raise-frame' to
> focus the frame.  It should not prevent `help-window-select' (or
> anything else) from selecting the window.

What makes you sure that it does prevent `help-window-select' from
selecting the window?

> The effect should, because of `help-window-select' = t, be that
> the *Help* window is selected.  Selection should not depend on
> whether `raise-frame' happens to also select/focus.

Then you know more than me.  `w32-grab-focus-on-raise', if nil, triggers
a DeferWindowPos type chain of events, see

http://msdn.microsoft.com/en-us/library/windows/desktop/ms632681%28v=vs.85%29.aspx

which is beyond my comprehension.

> ;; This somehow causes the window/frame NOT to be selected.
> ;; If non-nil then there is no problem.
> (setq w32-grab-focus-on-raise  nil)

Then leave it non-nil.

> Note that the doc string of `w32-grab-focus-on-raise'
> specifically does not say that a value of nil means that
> `raise-frame' takes the focus away (unfocuses).  It says
> only that a value of t means that `raise-frame' focuses
> the frame.
>
> Since nothing is said for nil, the presumption should be
> that a nil value has no particular effect on focus, i.e.,
> that it neither "grabs input focus", as does t, nor
> removes focus.

If you understand what it does, provide a suitable doc-string.

> And all of this code is anyway inside `with-help-window'
> because of `C-h v'.  So even if the bug were that
> `raise-frame' removed the focus (unlike what the
> `w-g-f-o-r' doc string says), `help-window-select'
> should anyway ensure that *Help* is focused in the end.

If you told us how `with-help-window' should deal with asynchronous
frame raise/focus events, we could try to find a solution.

> ----------------- What I said before ---------------
>> Found it, I guess.
>>
>> In addition to non-nil pop-up-frames and the other code sent
>> previously, do this: (setq w32-grab-focus-on-raise  nil)
>>
>> Then, as I described, when the *Help* frame already exists it is not
>> selected by C-h v etc.
>>
>> Now IIUC, that variable, `w32-grab-focus-on-raise', should only
>> stop Windows from having `raise-frame' always focus the frame.
>> That really is (should be) something different from this
>> (`help-window-select').
>>
>> IOW, I do not want `raise-frame' to automatically focus the
>> frame for input each time.  But I might want `help-window-select'
>> to select the *Help* frame.  Make sense?

I can only repeat myself: I don't understand what is at work here and
how this is supposed to work.  `help-window-select' simply selects the
window if certain conditions are met.  How selection is implemented and
what consequences it has is platform dependent and beyond its control.

martin

Previous Next

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