From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#19012: 25.0.50; `help-window-select' Date: Wed, 12 Nov 2014 21:12:54 -0800 (PST) Message-ID: <561951d1-fee4-44ea-bc22-d354b007601d@default> References: <5460F5B3.6040402@gmx.at> <8e78202d-5ac0-4df5-8195-9849dd7509b7@default> <5461C901.6060707@gmx.at> <3f833473-f246-4d57-95cd-2ac654d326c9@default> <5462561B.2030306@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1415855672 22643 80.91.229.3 (13 Nov 2014 05:14:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Nov 2014 05:14:32 +0000 (UTC) To: martin rudalics , 19012@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 13 06:14:25 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xomjf-0002Qh-FM for geb-bug-gnu-emacs@m.gmane.org; Thu, 13 Nov 2014 06:14:23 +0100 Original-Received: from localhost ([::1]:57870 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xomje-00079A-Qx for geb-bug-gnu-emacs@m.gmane.org; Thu, 13 Nov 2014 00:14:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39507) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XomjT-00078v-O7 for bug-gnu-emacs@gnu.org; Thu, 13 Nov 2014 00:14:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XomjK-0001HN-W5 for bug-gnu-emacs@gnu.org; Thu, 13 Nov 2014 00:14:11 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:33561) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XomjK-0001HJ-SW for bug-gnu-emacs@gnu.org; Thu, 13 Nov 2014 00:14:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XomjK-0003aO-Eo for bug-gnu-emacs@gnu.org; Thu, 13 Nov 2014 00:14:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 13 Nov 2014 05:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19012 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19012-submit@debbugs.gnu.org id=B19012.141585558613703 (code B ref 19012); Thu, 13 Nov 2014 05:14:02 +0000 Original-Received: (at 19012) by debbugs.gnu.org; 13 Nov 2014 05:13:06 +0000 Original-Received: from localhost ([127.0.0.1]:59007 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XomiN-0003Yp-Ph for submit@debbugs.gnu.org; Thu, 13 Nov 2014 00:13:04 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:51465) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XomiK-0003Y7-Fi for 19012@debbugs.gnu.org; Thu, 13 Nov 2014 00:13:01 -0500 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sAD5CvPf014932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Nov 2014 05:12:58 GMT Original-Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAD5Ct95000687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Nov 2014 05:12:57 GMT Original-Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAD5CsFq011413; Thu, 13 Nov 2014 05:12:55 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:95913 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' =3D 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' =3D 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 =09 '("*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. >=20 > In addition to non-nil pop-up-frames and the other code sent > previously, do this: (setq w32-grab-focus-on-raise nil) >=20 > Then, as I described, when the *Help* frame already exists it is not > selected by C-h v etc. >=20 > 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'). >=20 > 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?