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

Previous Next

Full log

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

From: Drew Adams <drew.adams <at> oracle.com>
To: martin rudalics <rudalics <at> gmx.at>, 19012 <at> debbugs.gnu.org
Subject: RE: bug#19012: 25.0.50; `help-window-select'
Date: Wed, 12 Nov 2014 21:12:54 -0800 (PST)

As the "discussion" with Stefan about what `special-display-function'
can or cannot do might have distracted from the bug description,
let me repeat the recipe to repro the problem, and this time
without including code to select the returned window (which is
irrelevant to the bug, as the previous recipe should have made
clear).

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.

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.

The recipe, after `emacs -Q' and evaluating the code below:

1. C-h v pop-up-frames RET
   That correctly creates the *Help* frame.  And because
   MS Windows alwayse focuses a new frame, it has the focus.
   OK so far.

2. Select the original frame (e.g. with the mouse), so that
   it, not *Help*, now has the focus.

3. C-h v help-window-select RET
   The *Help* window & frame are not selected/focused.
   They should be.

The code:

(setq pop-up-frames  t)

;; This should cause the *Help* window to be selected.
(setq help-window-select  t)

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

(add-to-list 'special-display-buffer-names
	      '("*Help*" foo ((background-color . "Thistle"))))

(defun foo (buf &optional args)
  (let (win)
    (setq win  (funcall special-display-function buf args))
    (raise-frame)
    win))

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.

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.



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

Previous Next

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