From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 10 11:42:52 2014 Received: (at submit) by debbugs.gnu.org; 10 Nov 2014 16:42:53 +0000 Received: from localhost ([127.0.0.1]:56174 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xns3I-0004kJ-HX for submit@debbugs.gnu.org; Mon, 10 Nov 2014 11:42:52 -0500 Received: from eggs.gnu.org ([208.118.235.92]:39491) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xns3F-0004k8-Sj for submit@debbugs.gnu.org; Mon, 10 Nov 2014 11:42:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xns35-0002qC-7N for submit@debbugs.gnu.org; Mon, 10 Nov 2014 11:42:49 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:49206) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xns35-0002q8-4b for submit@debbugs.gnu.org; Mon, 10 Nov 2014 11:42:39 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41095) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xns2w-0004tA-8N for bug-gnu-emacs@gnu.org; Mon, 10 Nov 2014 11:42:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xns2m-0002ic-T5 for bug-gnu-emacs@gnu.org; Mon, 10 Nov 2014 11:42:30 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:51707) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xns2m-0002hG-N7 for bug-gnu-emacs@gnu.org; Mon, 10 Nov 2014 11:42:20 -0500 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sAAGgInJ026662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 10 Nov 2014 16:42:19 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAAGgIrP020037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 10 Nov 2014 16:42:18 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAAGgHhj020025 for ; Mon, 10 Nov 2014 16:42:17 GMT MIME-Version: 1.0 Message-ID: Date: Mon, 10 Nov 2014 08:42:16 -0800 (PST) From: Drew Adams To: bug-gnu-emacs@gnu.org Subject: 25.0.50; `help-window-select' X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) The description of `other' in the Customize buffer (and the doc string) is incorrect. Or else the behavior is bugged. If *Help* is shown in its own frame (e.g. from *Help* being a special-display buffer), and if the option value is `other' (the default), then the *Help* window (and frame) are *not* selected, in contradiction to what the doc says. On MS Windows, at least, if the *Help* frame in this context does not yet exist then yes, that frame (and thus the *Help* window is selected - the frame gets the input focus. But that is because Windows always gives a newly created frame the focus. And if the frame exists already then no, the *Help* window and its frame are not selected. Focus stays with the frame where you invoked the help command. Note too that the description is anyway inadequate, because it seems to make the assumption that there *is* another window on the help window's frame: "unless the selected window is the only other window on the help window's frame" is not clear for the case where there is no such other window. In GNU Emacs 25.0.50.1 (i686-pc-mingw32) of 2014-10-20 on LEG570 Bzr revision: 118168 rgm@gnu.org-20141020195941-icp42t8ttcnud09g Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --enable-checking=3Dyes,glyphs CPPFLAGS=3D-DGLYPH_DEBUG=3D1' From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 10 12:28:26 2014 Received: (at 19012) by debbugs.gnu.org; 10 Nov 2014 17:28:26 +0000 Received: from localhost ([127.0.0.1]:56206 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnslO-0006MW-40 for submit@debbugs.gnu.org; Mon, 10 Nov 2014 12:28:26 -0500 Received: from mout.gmx.net ([212.227.17.21]:59894) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnslL-0006MG-Dt for 19012@debbugs.gnu.org; Mon, 10 Nov 2014 12:28:24 -0500 Received: from [88.117.81.84] ([88.117.81.84]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0McEDD-1XY8Wo3KT9-00JbIY; Mon, 10 Nov 2014 18:28:22 +0100 Message-ID: <5460F5B3.6040402@gmx.at> Date: Mon, 10 Nov 2014 18:28:19 +0100 From: martin rudalics MIME-Version: 1.0 To: Drew Adams , 19012@debbugs.gnu.org Subject: Re: bug#19012: 25.0.50; `help-window-select' References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:jTWIbVm/E3Nici9DVxjQ2RT1Daj52z+gA0nGMoOgIOnaVTTTdn8 rAk/iaa8J8pqmp1UisChAYX0x0X5QlN/qFY++hQtYhVYug3HowUGLBBWsNVBJ9jwU1+uQ8M xNqDSprRDhQtM2MMVK1bKtx5x1h28PQks+bM9LpcUAs7PwkRogpbCBv6Hi5Ew0EbwgNdPJM 4oy6ALVuaSCRIHHv/XUnA== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > The description of `other' in the Customize buffer (and the doc string) > is incorrect. Or else the behavior is bugged. > > If *Help* is shown in its own frame (e.g. from *Help* being a > special-display buffer), and if the option value is `other' (the > default), then the *Help* window (and frame) are *not* selected, in > contradiction to what the doc says. > > On MS Windows, at least, if the *Help* frame in this context does not > yet exist then yes, that frame (and thus the *Help* window is selected - > the frame gets the input focus. But that is because Windows always > gives a newly created frame the focus. And if the frame exists already > then no, the *Help* window and its frame are not selected. Focus stays > with the frame where you invoked the help command. It does get selected here on Windows XP. What happens when you set `help-window-select' to t? Did you create the *Help* window with `with-help-window'? If so, please tell me the value of the 'quit-restore window parameter of the *Help* window. > Note too that the description is anyway inadequate, because it seems to > make the assumption that there *is* another window on the help window's > frame: "unless the selected window is the only other window on the help > window's frame" is not clear for the case where there is no such other > window. When there is "no such other window" the selected window "is not the only other window on the help window's frame". What am I missing? martin From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 10 13:23:21 2014 Received: (at 19012) by debbugs.gnu.org; 10 Nov 2014 18:23:21 +0000 Received: from localhost ([127.0.0.1]:56260 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XntcW-0008QD-S0 for submit@debbugs.gnu.org; Mon, 10 Nov 2014 13:23:21 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:24245) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XntcT-0008Q1-Mn for 19012@debbugs.gnu.org; Mon, 10 Nov 2014 13:23:18 -0500 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sAAINFT2009421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Nov 2014 18:23:16 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAAINEKr023671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Nov 2014 18:23:15 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAAINDsA015003; Mon, 10 Nov 2014 18:23:14 GMT MIME-Version: 1.0 Message-ID: <8e78202d-5ac0-4df5-8195-9849dd7509b7@default> Date: Mon, 10 Nov 2014 10:23:13 -0800 (PST) From: Drew Adams To: martin rudalics , 19012@debbugs.gnu.org Subject: RE: bug#19012: 25.0.50; `help-window-select' References: <5460F5B3.6040402@gmx.at> In-Reply-To: <5460F5B3.6040402@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.9 (--) > > The description of `other' in the Customize buffer (and the doc > > string) is incorrect. Or else the behavior is bugged. > > > > If *Help* is shown in its own frame (e.g. from *Help* being a > > special-display buffer), and if the option value is `other' (the > > default), then the *Help* window (and frame) are *not* selected, > > in contradiction to what the doc says. > > > > On MS Windows, at least, if the *Help* frame in this context does > > not yet exist then yes, that frame (and thus the *Help* window is > > selected - the frame gets the input focus. But that is because > > Windows always gives a newly created frame the focus. And if the > > frame exists already then no, the *Help* window and its frame are > > not selected. Focus stays with the frame where you invoked the > > help command. >=20 > It does get selected here on Windows XP. What happens when you set > `help-window-select' to t? The help window is still not selected. > Did you create the *Help* window with `with-help-window'? > If so, please tell me the value of the 'quit-restore window > parameter of the *Help* window. No, I guess not (see below), but I'm not sure. And I did not read the note in the doc saying, "This option has effect if and only if the help window was created by `with-help-window'" (That sentence is missing a period, BTW.) Mea culpa. So I guess maybe what I said in the bug report about the behavior not matching the doc is wrong (i.e., is irrelevant). The part about the doc not being too clear might still help you, however. If not, I guess you can close the bug. I am on Windows 7 (but on XP the behavior was the same). This is the relevant code: (add-to-list 'special-display-buffer-names (list "*Help*" '1on1-display-*Help*-frame (list (cons 'background-color 1on1-help-frame-background) (cons 'mouse-color 1on1-help-frame-mouse+cursor-color) (cons 'cursor-color 1on1-help-frame-mouse+cursor-color) '(height . 40)))) (defun 1on1-display-*Help*-frame (buf &optional args) "Display *Help* buffer in its own frame. `special-display-function' is used to do the actual displaying. BUF and ARGS are the arguments to `special-display-function'." (let ((old-ptr-shape (and (boundp 'x-pointer-shape) x-pointer-shape)) return-window) (when (boundp 'x-pointer-xterm) (setq x-pointer-shape x-pointer-xterm)= ) (setq return-window (select-window (funcall special-display-function buf args))) (raise-frame) (setq x-pointer-shape old-ptr-shape) return-window)) Does that mean that `with-help-window' is not involved? Maybe so, but it's not obvious to me. How is a user supposed to know whether this option applies, i.e., whether "the help window was created by `with-help-window'? And why shouldn't such an option apply in general for the help window? Why must it depend on how the window is created? > > Note too that the description is anyway inadequate, because it > > seems to make the assumption that there *is* another window on > > the help window's frame: "unless the selected window is the only > > other window on the help window's frame" is not clear for the > > case where there is no such other window. >=20 > When there is "no such other window" the selected window "is not the > only other window on the help window's frame". What am I missing? Maybe so, but it's not very clear, IMO. The vacuous case should be mentioned explicitly, I think, and not depend for its understanding on finessing the logic. Just say, for value `other', that "if the help window is alone in its frame then it is selected". With the scenario I described (*Help* is alone in its frame, in a dedicated window, and the *Help* frame exists prior to calling the help command) and with a value of `other' or `t', the *Help* window is *not* selected. With your interpretation, the "unless" condition is false, so the *Help* window should be selected (except that perhaps `with-help-window' is not involved - dunno about that). From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 11 03:30:09 2014 Received: (at 19012) by debbugs.gnu.org; 11 Nov 2014 08:30:09 +0000 Received: from localhost ([127.0.0.1]:56845 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xo6pz-0000c0-1J for submit@debbugs.gnu.org; Tue, 11 Nov 2014 03:30:08 -0500 Received: from mout.gmx.net ([212.227.17.22]:53970) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xo6pu-0000bO-LD for 19012@debbugs.gnu.org; Tue, 11 Nov 2014 03:30:04 -0500 Received: from [194.166.83.42] ([194.166.83.42]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MQRZw-1XQyM627Dw-00TntT; Tue, 11 Nov 2014 09:29:58 +0100 Message-ID: <5461C901.6060707@gmx.at> Date: Tue, 11 Nov 2014 09:29:53 +0100 From: martin rudalics MIME-Version: 1.0 To: Drew Adams , 19012@debbugs.gnu.org Subject: Re: bug#19012: 25.0.50; `help-window-select' References: <5460F5B3.6040402@gmx.at> <8e78202d-5ac0-4df5-8195-9849dd7509b7@default> In-Reply-To: <8e78202d-5ac0-4df5-8195-9849dd7509b7@default> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:oTD4+bKw8nPLFow9SgzenjFiuUh2Pq3zWo271ftkM8Z9aK00CUU 3iBd8Z6O8bADYpgzmKnxBPlog7KGLsDc26drhWHJLA5jmF1e7JnO8gG6/xDtaxLTjmBH1NO zMFPrWhDCOAeJdVoE6lBbZib5QdujM//V3v0USVq9Rug2ZFr1+7CaPR3UwpzL0w4AFzsXbH tIoFA9bzRwgpVKneLSs7w== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > This is the relevant code: > > (add-to-list > 'special-display-buffer-names > (list "*Help*" '1on1-display-*Help*-frame > (list (cons 'background-color 1on1-help-frame-background) > (cons 'mouse-color 1on1-help-frame-mouse+cursor-color) > (cons 'cursor-color 1on1-help-frame-mouse+cursor-color) > '(height . 40)))) > > (defun 1on1-display-*Help*-frame (buf &optional args) > "Display *Help* buffer in its own frame. > `special-display-function' is used to do the actual displaying. > BUF and ARGS are the arguments to `special-display-function'." > (let ((old-ptr-shape (and (boundp 'x-pointer-shape) x-pointer-shape)) > return-window) > (when (boundp 'x-pointer-xterm) (setq x-pointer-shape x-pointer-xterm)) > (setq return-window > (select-window (funcall special-display-function buf args))) > (raise-frame) > (setq x-pointer-shape old-ptr-shape) > return-window)) > > Does that mean that `with-help-window' is not involved? Who creates the *Help* buffer and who calls `display-buffer' in the case at hand? > Maybe so, > but it's not obvious to me. How is a user supposed to know whether > this option applies, i.e., whether "the help window was created by > `with-help-window'? By trial and error, I suppose. I wrote `with-help-window' seven years ago because there were many complaints about the previous behavior. And I hardly had any complaints since that. `with-help-window' has to cater for people who don't know what an option is or how it can be customized. Still, those people want to get help via C-h and get rid of that help afterwards. When such people later find that the help window gets selected in some unintuitive way they can tune the behavior using this option. > And why shouldn't such an option apply in general for the help window? > Why must it depend on how the window is created? Because it relies on things set up correctly at the time the window is created. Most of the work I put into `with-help-window' was about storing information that would allow quitting to return to the previous state as smoothly as possible. > Maybe so, but it's not very clear, IMO. The vacuous case should be > mentioned explicitly, I think, and not depend for its understanding on > finessing the logic. Just say, for value `other', that "if the help > window is alone in its frame then it is selected". I'll do that. > With the scenario I described (*Help* is alone in its frame, in a > dedicated window, and the *Help* frame exists prior to calling the > help command) and with a value of `other' or `t', the *Help* window > is *not* selected. > > With your interpretation, the "unless" condition is false, so the > *Help* window should be selected Indeed. It would be a bug if it didn't get selected. > (except that perhaps > `with-help-window' is not involved - dunno about that). martin From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 11 09:26:15 2014 Received: (at 19012) by debbugs.gnu.org; 11 Nov 2014 14:26:15 +0000 Received: from localhost ([127.0.0.1]:56977 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XoCOc-0001qd-Qx for submit@debbugs.gnu.org; Tue, 11 Nov 2014 09:26:15 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:35059) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XoCOZ-0001qT-AS for 19012@debbugs.gnu.org; Tue, 11 Nov 2014 09:26:11 -0500 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sABEQ9Za006220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Nov 2014 14:26:10 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id sABEQ8pR004717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Nov 2014 14:26:09 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sABEQ8x5004197; Tue, 11 Nov 2014 14:26:08 GMT MIME-Version: 1.0 Message-ID: <3f833473-f246-4d57-95cd-2ac654d326c9@default> Date: Tue, 11 Nov 2014 06:26:08 -0800 (PST) From: Drew Adams To: martin rudalics , 19012@debbugs.gnu.org Subject: RE: bug#19012: 25.0.50; `help-window-select' References: <5460F5B3.6040402@gmx.at> <8e78202d-5ac0-4df5-8195-9849dd7509b7@default> <5461C901.6060707@gmx.at> In-Reply-To: <5461C901.6060707@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.8 (--) > Who creates the *Help* buffer and who calls `display-buffer' in the > case at hand? The usual displayers of *Help*: `C-h f', `C-h v', `C-h m', `C-h b', ... And those do generally use `with-help-window'. But as I mentioned, `display-buffer' in this case uses the logic of `special-display': (add-to-list 'special-display-buffer-names (list "*Help*" '1on1-display-*Help*-frame (list (cons 'background-color 1on1-help-frame-background) (cons 'mouse-color 1on1-help-frame-mouse+cursor-color) (cons 'cursor-color 1on1-help-frame-mouse+cursor-color) '(height . 40)))) (defun 1on1-display-*Help*-frame (buf &optional args) "Display *Help* buffer in its own frame. `special-display-function' is used to do the actual displaying. BUF and ARGS are the arguments to `special-display-function'." (let ((old-ptr-shape (and (boundp 'x-pointer-shape) x-pointer-shape)) return-window) (when (boundp 'x-pointer-xterm) (setq x-pointer-shape x-pointer-xterm)) (setq return-window (select-window (funcall special-display-function buf args))) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (raise-frame) (setq x-pointer-shape old-ptr-shape) return-window)) ^^^^^^^^^^^^^ > > but it's not obvious to me. How is a user supposed to know > > whether this option applies, i.e., whether "the help window > > was created by `with-help-window'? >=20 > By trial and error, I suppose... [When] the help window > gets selected in some unintuitive way they can tune the behavior > using this option. OK. It doesn't seem to work in the case I presented: *Help* shown in a dedicated window in a separate frame. > > say, for value `other', that "if the help window is alone in > > its frame then it is selected". >=20 > I'll do that. Thanks. > Indeed. It would be a bug if it didn't get selected. That was my hope. It does not get selected, even with an option value of `t'. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 11 13:32:02 2014 Received: (at 19012) by debbugs.gnu.org; 11 Nov 2014 18:32:02 +0000 Received: from localhost ([127.0.0.1]:57588 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XoGEU-0000sJ-0d for submit@debbugs.gnu.org; Tue, 11 Nov 2014 13:32:02 -0500 Received: from mout.gmx.net ([212.227.15.15]:61415) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XoGER-0000rr-Pb for 19012@debbugs.gnu.org; Tue, 11 Nov 2014 13:32:00 -0500 Received: from [62.47.250.33] ([62.47.250.33]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MD9NE-1XnBMv32U8-00Gb8m; Tue, 11 Nov 2014 19:31:57 +0100 Message-ID: <5462561B.2030306@gmx.at> Date: Tue, 11 Nov 2014 19:31:55 +0100 From: martin rudalics MIME-Version: 1.0 To: Drew Adams , 19012@debbugs.gnu.org Subject: Re: bug#19012: 25.0.50; `help-window-select' References: <5460F5B3.6040402@gmx.at> <8e78202d-5ac0-4df5-8195-9849dd7509b7@default> <5461C901.6060707@gmx.at> <3f833473-f246-4d57-95cd-2ac654d326c9@default> In-Reply-To: <3f833473-f246-4d57-95cd-2ac654d326c9@default> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ck0fL8mHvaAPcEb/u1d6YVwAURF0Tae/uJu17x5M4/Mu5yxQKwl rDOFANavtXYbBmUaD5Kg0NeDPeY7kBl+MwuQZeK3lzV8DXW6+HybZmLRuUb00qr2oFGNeW4 5WHPOohacd6UBWBSFBE9ONabwoXUD+Jt+GxDjDYCC8B2gC9UdU05bWBtYsu4+l0QP6r/uzC xXuqt6NT3+uSj9kN5lLqQ== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) This one is at least dubious > (setq return-window (select-window ^^^^^^^^^^^^^ > (funcall special-display-function buf args))) According to its doc-string `display-buffer' should Display BUFFER-OR-NAME in some window, without selecting it. As a rule, `display-buffer' should not select the window used. Otherwise, `with-help-window' cannot determine the correct window to select when quitting help. However, with the current release and trunk, emacs -Q and (defun 1on1-display-*Help*-frame (buf &optional args) "Display *Help* buffer in its own frame. `special-display-function' is used to do the actual displaying. BUF and ARGS are the arguments to `special-display-function'." (let ((old-ptr-shape (and (boundp 'x-pointer-shape) x-pointer-shape)) return-window) (when (boundp 'x-pointer-xterm) (setq x-pointer-shape x-pointer-xterm)) (setq return-window (select-window (funcall special-display-function buf args))) (raise-frame) (setq x-pointer-shape old-ptr-shape) return-window)) (add-to-list 'special-display-buffer-names (list "*Help*" '1on1-display-*Help*-frame (list '(height . 40)))) the *Help* window is always selected here after C-h f, C-h v, ... martin From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 11 14:01:31 2014 Received: (at 19012) by debbugs.gnu.org; 11 Nov 2014 19:01:31 +0000 Received: from localhost ([127.0.0.1]:57600 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XoGh0-0001Yw-CV for submit@debbugs.gnu.org; Tue, 11 Nov 2014 14:01:30 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:33407) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XoGgy-0001Yo-LT for 19012@debbugs.gnu.org; Tue, 11 Nov 2014 14:01:29 -0500 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sABJ1Rwk011847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Nov 2014 19:01:27 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id sABJ1Put000921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Nov 2014 19:01:26 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sABJ1P2m020583; Tue, 11 Nov 2014 19:01:25 GMT MIME-Version: 1.0 Message-ID: Date: Tue, 11 Nov 2014 11:01:24 -0800 (PST) From: Drew Adams To: martin rudalics , 19012@debbugs.gnu.org Subject: RE: bug#19012: 25.0.50; `help-window-select' 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> In-Reply-To: <5462561B.2030306@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.8 (--) > This one is at least dubious > > (setq return-window (select-window > > ^^^^^^^^^^^^^ > > (funcall special-display-function buf args)= )) > According to its doc-string `display-buffer' should >=20 > Display BUFFER-OR-NAME in some window, without selecting it. >=20 > As a rule, `display-buffer' should not select the window used. > Otherwise, `with-help-window' cannot determine the correct window to > select when quitting help. That is a new restriction (beginning with `display-buffer-alist'), if it is one. `display-buffer' should, as it did prior to `display-buffer-alist'= , respect `special-display-buffer-names' and `special-display-function', which has no such restriction wrt its value's behavior, AFAIK. And there should be *no reason* for such a restriction. The addition of the zillion things that complicated `display-buffer' was supposed to make it *more* flexible, not less, letting users get more and finer control over the behavior - not losing the ability to use an arbitrary display function. If `display-buffer' with default values for everything does not want to select the displayed buffer, fine. But `display-buffer' trying to prohibit a user-defined display function from selecting (or doing anything else) would be unnecessarily restrictive: it is not `display-buffer's business what a user-defined "display" function might do. Besides which, "according to its doc-string `display-buffer'..." is not a reason. Its doc string can say nothing about what user-defined display function `special-display-function' does, beyond what the doc for that variable says. It says (and should say) nothing about not selecting the displayed buffer's window in such a case. > However, with the current release and trunk, emacs -Q and > (defun 1on1-display-*Help*-frame (buf &optional args) ... > (add-to-list 'special-display-buffer-names... > the *Help* window is always selected here after C-h f, C-h v, ... Well, there is also non-nil `pop-up-frames' etc. But I see that from `emacs -Q', with only the above and non-nil `pop-up-frames', what you say is true, so there must be something else involved as well. I will take a look when I get some time. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 11 16:04:59 2014 Received: (at 19012) by debbugs.gnu.org; 11 Nov 2014 21:04:59 +0000 Received: from localhost ([127.0.0.1]:57683 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XoIcU-0005qE-Qa for submit@debbugs.gnu.org; Tue, 11 Nov 2014 16:04:59 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:49179) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XoIcS-0005q6-QO for 19012@debbugs.gnu.org; Tue, 11 Nov 2014 16:04:57 -0500 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sABL4tdS007972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Nov 2014 21:04:55 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sABL4sM6018556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Nov 2014 21:04:54 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sABL4s4Z018548; Tue, 11 Nov 2014 21:04:54 GMT MIME-Version: 1.0 Message-ID: Date: Tue, 11 Nov 2014 13:04:53 -0800 (PST) From: Drew Adams To: martin rudalics , 19012@debbugs.gnu.org Subject: RE: bug#19012: 25.0.50; `help-window-select' 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> 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)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.8 (--) > Well, there is also non-nil `pop-up-frames' etc. But I see that > from `emacs -Q', with only the above and non-nil `pop-up-frames', what > you say is true, so there must be something else involved as well. I > will take a look when I get some time. 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? From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 11 17:16:02 2014 Received: (at 19012) by debbugs.gnu.org; 11 Nov 2014 22:16:02 +0000 Received: from localhost ([127.0.0.1]:57708 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XoJjG-0007WB-Cp for submit@debbugs.gnu.org; Tue, 11 Nov 2014 17:16:02 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:62918) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XoJjF-0007Vl-Eq for 19012@debbugs.gnu.org; Tue, 11 Nov 2014 17:16:01 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIMAOatTlRLd+sd/2dsb2JhbABcgw6DYoZ+yDmDFwMEAgKBHBcBAXyEAwEBAwFWIwULCzQSFBgNJIhLCctyAQEBAQEFAQEBAR6RCAeESwWLZKY8gW+EFh+CegEBAQ X-IPAS-Result: AvIMAOatTlRLd+sd/2dsb2JhbABcgw6DYoZ+yDmDFwMEAgKBHBcBAXyEAwEBAwFWIwULCzQSFBgNJIhLCctyAQEBAQEFAQEBAR6RCAeESwWLZKY8gW+EFh+CegEBAQ X-IronPort-AV: E=Sophos;i="5.04,797,1406606400"; d="scan'208";a="96672234" Received: from 75-119-235-29.dsl.teksavvy.com (HELO pastel.home) ([75.119.235.29]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Nov 2014 17:16:00 -0500 Received: by pastel.home (Postfix, from userid 20848) id D193A848C; Tue, 11 Nov 2014 17:16:00 -0500 (EST) From: Stefan Monnier To: Drew Adams Subject: Re: bug#19012: 25.0.50; `help-window-select' Message-ID: 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> Date: Tue, 11 Nov 2014 17:16:00 -0500 In-Reply-To: (Drew Adams's message of "Tue, 11 Nov 2014 11:01:24 -0800 (PST)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 19012 Cc: martin rudalics , 19012@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > That is a new restriction (beginning with `display-buffer-alist'), if it Hmm... let's see: % emacs22 -Q C-h f display-buffer RET ... Make buffer appear in some window but don't select it. ... If you want, I can try some other versions, maybe you just got unlucky? Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 11 18:10:56 2014 Received: (at 19012) by debbugs.gnu.org; 11 Nov 2014 23:10:57 +0000 Received: from localhost ([127.0.0.1]:57719 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XoKaO-0000JO-Es for submit@debbugs.gnu.org; Tue, 11 Nov 2014 18:10:56 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:38694) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XoKaM-0000JG-5D for 19012@debbugs.gnu.org; Tue, 11 Nov 2014 18:10:54 -0500 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sABNAqSJ021694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Nov 2014 23:10:53 GMT 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 sABNAomn006563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Nov 2014 23:10:51 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sABNAonx003316; Tue, 11 Nov 2014 23:10:50 GMT MIME-Version: 1.0 Message-ID: Date: Tue, 11 Nov 2014 15:10:49 -0800 (PST) From: Drew Adams To: Stefan Monnier Subject: RE: bug#19012: 25.0.50; `help-window-select' 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> 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)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 19012 Cc: martin rudalics , 19012@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.8 (--) > > That is a new restriction (beginning with `display-buffer-alist'), >=20 > Hmm... let's see: > % emacs22 -Q > C-h f display-buffer RET > ... > Make buffer appear in some window but don't select it. > ... >=20 > If you want, I can try some other versions, maybe you just got > unlucky? Ooh, Smartypants! Clearly you just want to be snarky and not read what I wrote, which is that **when `display-buffer' uses `special-display-function'** there is no such restriction. `display-buffer' essentially delegates behavior in that context. A one-liner summary of what `display-buffer' does will not and cannot, of course, go into such things. The full doc for it does refer to `special-display-buffer-names', however, which refers to `special-display-function'. And that doc makes it quite clear: ;; Emacs 22 `C-h v special-display-buffer-names' ... In the second case, FUNCTION is called with BUFFER as the first argument, followed by the OTHER-ARGS--it can display BUFFER in any way it likes. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ All this is done by the function found in `special-display-function'. There are no limits, beyond its arity and return value, on what `special-display-function' does. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 11 20:49:33 2014 Received: (at 19012) by debbugs.gnu.org; 12 Nov 2014 01:49:33 +0000 Received: from localhost ([127.0.0.1]:57977 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XoN3t-0004UV-30 for submit@debbugs.gnu.org; Tue, 11 Nov 2014 20:49:33 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:14105) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XoN3r-0004UM-H0 for 19012@debbugs.gnu.org; Tue, 11 Nov 2014 20:49:31 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvAMAOatTlRLd+sd/2dsb2JhbABcgw6DYoZ+yDmDGgQCAoEcFwEBfIQDAQEDAVYjBQsLNBIUGA0kiEsJy3IBAQEBAQUBAQEBHpEIB4RLBYtkky6GdowYgW+EFh+CegEBAQ X-IPAS-Result: AvAMAOatTlRLd+sd/2dsb2JhbABcgw6DYoZ+yDmDGgQCAoEcFwEBfIQDAQEDAVYjBQsLNBIUGA0kiEsJy3IBAQEBAQUBAQEBHpEIB4RLBYtkky6GdowYgW+EFh+CegEBAQ X-IronPort-AV: E=Sophos;i="5.04,797,1406606400"; d="scan'208";a="96682222" Received: from 75-119-235-29.dsl.teksavvy.com (HELO pastel.home) ([75.119.235.29]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Nov 2014 20:49:30 -0500 Received: by pastel.home (Postfix, from userid 20848) id 6ED70848C; Tue, 11 Nov 2014 20:49:30 -0500 (EST) From: Stefan Monnier To: Drew Adams Subject: Re: bug#19012: 25.0.50; `help-window-select' Message-ID: 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> Date: Tue, 11 Nov 2014 20:49:30 -0500 In-Reply-To: (Drew Adams's message of "Tue, 11 Nov 2014 15:10:49 -0800 (PST)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 19012 Cc: martin rudalics , 19012@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > Clearly you just want to be snarky and not read what I wrote, > which is that **when `display-buffer' uses > `special-display-function'** there is no such restriction. Of course special-display-function can do whatever it wants, but if it doesn't follow the behavior described by display-buffer's docstring, it may break some callers. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 11 21:36:16 2014 Received: (at 19012) by debbugs.gnu.org; 12 Nov 2014 02:36:16 +0000 Received: from localhost ([127.0.0.1]:58014 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XoNn5-0007lI-Tb for submit@debbugs.gnu.org; Tue, 11 Nov 2014 21:36:16 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:41073) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XoNn3-0007l6-VI for 19012@debbugs.gnu.org; Tue, 11 Nov 2014 21:36:14 -0500 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sAC2a92I021267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Nov 2014 02:36:10 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAC2a8mO002494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2014 02:36:08 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id sAC2a7gE023879; Wed, 12 Nov 2014 02:36:07 GMT MIME-Version: 1.0 Message-ID: <0ea154f5-dabf-4997-8edb-7fe15d8a261e@default> Date: Tue, 11 Nov 2014 18:36:06 -0800 (PST) From: Drew Adams To: Stefan Monnier Subject: RE: bug#19012: 25.0.50; `help-window-select' 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> 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)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 19012 Cc: martin rudalics , 19012@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.8 (--) > > Clearly you just want to be snarky and not read what I wrote, > > which is that **when `display-buffer' uses > > `special-display-function'** there is no such restriction. >=20 > Of course special-display-function can do whatever it wants, > but if it doesn't follow the behavior described by > display-buffer's docstring, it may break some callers. The behavior specified by display-buffer's doc string is just whatever `special-display-function' does - nothing more or less, when `special-display-function' is used. So there is *no* behavior for `special-display-function' for to follow, other than its own behavior. `display-buffer' says nothing about `display-buffer' behavior in this case - it says only that it delegates `display-buffer' behavior to `special-display-function'. That's the point of providing for `special-display-function'. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 11 23:11:45 2014 Received: (at 19012) by debbugs.gnu.org; 12 Nov 2014 04:11:45 +0000 Received: from localhost ([127.0.0.1]:58041 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XoPHU-0003Ws-KB for submit@debbugs.gnu.org; Tue, 11 Nov 2014 23:11:44 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:58309) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XoPHS-0003Wg-BL for 19012@debbugs.gnu.org; Tue, 11 Nov 2014 23:11:43 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIMAOatTlRLd+sd/2dsb2JhbABcgw6DYoZ+yDmDGAIEAgKBHBcBAXyEAwEBAwFWIwULCzQSFBgNJIhLCctyAQEBAQEFAQEBAR6RCAeESwWLZJMukH2CEYFvhBYfgnoBAQE X-IPAS-Result: AvIMAOatTlRLd+sd/2dsb2JhbABcgw6DYoZ+yDmDGAIEAgKBHBcBAXyEAwEBAwFWIwULCzQSFBgNJIhLCctyAQEBAQEFAQEBAR6RCAeESwWLZJMukH2CEYFvhBYfgnoBAQE X-IronPort-AV: E=Sophos;i="5.04,797,1406606400"; d="scan'208";a="96694508" Received: from 75-119-235-29.dsl.teksavvy.com (HELO pastel.home) ([75.119.235.29]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Nov 2014 23:11:41 -0500 Received: by pastel.home (Postfix, from userid 20848) id 734F5848C; Tue, 11 Nov 2014 23:11:41 -0500 (EST) From: Stefan Monnier To: Drew Adams Subject: Re: bug#19012: 25.0.50; `help-window-select' Message-ID: 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> <0ea154f5-dabf-4997-8edb-7fe15d8a261e@default> Date: Tue, 11 Nov 2014 23:11:41 -0500 In-Reply-To: <0ea154f5-dabf-4997-8edb-7fe15d8a261e@default> (Drew Adams's message of "Tue, 11 Nov 2014 18:36:06 -0800 (PST)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 19012 Cc: martin rudalics , 19012@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > So there is *no* behavior for `special-display-function' for > to follow, other than its own behavior. Let me restate what I said in clearer terms. Of course you're free to do whatever you want in special-display-function, but if it doesn't follow the behavior described by display-buffer's docstring and you get undesirable behavior, then I will consider it as a bug in *your* code rather than in Emacs. -- Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 12 02:18:18 2014 Received: (at 19012) by debbugs.gnu.org; 12 Nov 2014 07:18:18 +0000 Received: from localhost ([127.0.0.1]:58079 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XoSC2-0002E4-B3 for submit@debbugs.gnu.org; Wed, 12 Nov 2014 02:18:18 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:21141) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XoSC0-0002Dq-0k for 19012@debbugs.gnu.org; Wed, 12 Nov 2014 02:18:16 -0500 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sAC7IErw001715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Nov 2014 07:18:14 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id sAC7IDUl029665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2014 07:18:13 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id sAC7ICuf029617; Wed, 12 Nov 2014 07:18:12 GMT MIME-Version: 1.0 Message-ID: <9b9d2f61-0c72-48ce-babc-19c269eb900b@default> Date: Tue, 11 Nov 2014 23:18:11 -0800 (PST) From: Drew Adams To: Stefan Monnier Subject: RE: bug#19012: 25.0.50; `help-window-select' 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> <0ea154f5-dabf-4997-8edb-7fe15d8a261e@default> 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)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 19012 Cc: martin rudalics , 19012@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.8 (--) > > So there is *no* behavior for `special-display-function' > > to follow, other than its own behavior. >=20 > Let me restate what I said in clearer terms. Of course you're > free to do whatever you want in special-display-function, but > if it doesn't follow the behavior described by display-buffer's=20 > docstring and you get undesirable behavior, then I will > consider it as a bug in *your* code rather than in Emacs. And you will be wrong, at least wrt what `display-buffer' has said about its own behavior and wrt what its behavior has been. It is not a bug, according to what `display-buffer' says about itself, for it to delegate its behavior to `special-display-function'. That *is* its intended behavior when `special-display-function' is used. If it interferes with that delegation in some way, that is a bug. If `display-buffer' itself "doesn't follow the behavior described by display-buffer's docstring" then that is a bug in `display-buffer'. Of course, as Mr Emacs, you are free to change the behavior of `display-buffer', or `car', or `setq' anyway you like. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 13 00:13:06 2014 Received: (at 19012) by debbugs.gnu.org; 13 Nov 2014 05:13:06 +0000 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 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 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 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 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 MIME-Version: 1.0 Message-ID: <561951d1-fee4-44ea-bc22-d354b007601d@default> Date: Wed, 12 Nov 2014 21:12:54 -0800 (PST) From: Drew Adams To: martin rudalics , 19012@debbugs.gnu.org Subject: RE: bug#19012: 25.0.50; `help-window-select' 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> 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)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.9 (--) 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? From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 13 02:45:05 2014 Received: (at 19012) by debbugs.gnu.org; 13 Nov 2014 07:45:05 +0000 Received: from localhost ([127.0.0.1]:59045 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xop5U-0007iF-Sq for submit@debbugs.gnu.org; Thu, 13 Nov 2014 02:45:05 -0500 Received: from mout.gmx.net ([212.227.17.21]:63271) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xop5R-0007hY-To for 19012@debbugs.gnu.org; Thu, 13 Nov 2014 02:45:03 -0500 Received: from [88.117.59.125] ([88.117.59.125]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LyA2L-1Y1Fgj1SR3-015Xgm; Thu, 13 Nov 2014 08:44:56 +0100 Message-ID: <54646172.7020801@gmx.at> Date: Thu, 13 Nov 2014 08:44:50 +0100 From: martin rudalics MIME-Version: 1.0 To: Drew Adams , 19012@debbugs.gnu.org Subject: Re: bug#19012: 25.0.50; `help-window-select' 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> <561951d1-fee4-44ea-bc22-d354b007601d@default> In-Reply-To: <561951d1-fee4-44ea-bc22-d354b007601d@default> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:QtIThMnVhUDibtJljDC9PfU7RGpcZrFwRl0C0eoPTEHUZFxHvih MB2tGV0Rbc/i4iEjqeg/xN24WWBWoE4hJ2ChMgkThty5s9EhoQPiJwn7S4c/j2GiOmXXLQx mFbtc3ubPmWhKym0IrZP2wF77ad/38Li0+EC5a/koy2BUgQOns4aOFdl/CVYHEKYYmQ8h0d reF7fDhmcOGQIYy0OOgNQ== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 13 10:24:01 2014 Received: (at 19012) by debbugs.gnu.org; 13 Nov 2014 15:24:01 +0000 Received: from localhost ([127.0.0.1]:59505 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XowFc-0006gJ-I8 for submit@debbugs.gnu.org; Thu, 13 Nov 2014 10:24:01 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:32503) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XowFa-0006gB-QJ for 19012@debbugs.gnu.org; Thu, 13 Nov 2014 10:23:59 -0500 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sADFNvRJ019937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Nov 2014 15:23:58 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sADFNtsc017132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Nov 2014 15:23:55 GMT 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 sADFNskT017107; Thu, 13 Nov 2014 15:23:55 GMT MIME-Version: 1.0 Message-ID: Date: Thu, 13 Nov 2014 07:23:54 -0800 (PST) From: Drew Adams To: martin rudalics , 19012@debbugs.gnu.org Subject: RE: bug#19012: 25.0.50; `help-window-select' 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> <561951d1-fee4-44ea-bc22-d354b007601d@default> <54646172.7020801@gmx.at> In-Reply-To: <54646172.7020801@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -3.3 (---) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > 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. >=20 > What makes you sure that it does prevent `help-window-select' from > selecting the window? I did not say that it prevents that, and certainly not that I am sure that it prevents that. Please read what I actually said. > > 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. >=20 > Then you know more than me. =20 Again, I think you are not reading well what I wrote. I claim nothing about what is actually happening in the code. I reported symptoms, and I stated that there should not be such a dependency. I did not say that there is any such dependency. > `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=3Dvs.85%29.aspx > which is beyond my comprehension. If that article is beyond your comprehension then it is most likely beyond mine as well. But I mentioned an *Emacs* option. Emacs decides the behavior of that option. I have said nothing about the Emacs implementation. I care about the resulting behavior, not how the bug is fixed. > > ;; 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) >=20 > Then leave it non-nil. I've been clear that (a) I do not want `raise-frame' to focus frames, and that (b) whether I, as one user, want that behavior or not, the behavior of that option should not affect whether `help-window-select' works. > > 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. >=20 > If you understand what it does, provide a suitable doc-string. Again, you are misreading, it seems. (a) I did not say that I understand what it actually does (beyond the bugged symptoms I reported). (b) I made it clear that the bug reported is about the behavior, not a 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. >=20 > If you told us how `with-help-window' should deal with > asynchronous frame raise/focus events, we could try to find > a solution. 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. I have nothing to say about the implementation of `with-help-window'. I reported a bug in behavior. It seems clear from your "if-you-know-so-much-then-fix-it" over and over that you do not want to work on a fix for this. That's your right, of course. I reported the bug. You clarified some things about it. Maybe someday Someone (TM) will try to fix it. Maybe not. > 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. Fair enough. I have no idea either what combination of code causes the bugged behavior. One place (for Someone (TM)) to look might be (just a guess) the code that implements and uses `w32-grab-focus-on-raise'. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 13 11:28:58 2014 Received: (at 19012) by debbugs.gnu.org; 13 Nov 2014 16:28:58 +0000 Received: from localhost ([127.0.0.1]:59567 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XoxGT-0008Po-Ll for submit@debbugs.gnu.org; Thu, 13 Nov 2014 11:28:57 -0500 Received: from mout.gmx.net ([212.227.15.15]:55975) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XoxGQ-0008Pf-Kb for 19012@debbugs.gnu.org; Thu, 13 Nov 2014 11:28:56 -0500 Received: from [91.113.3.148] ([91.113.3.148]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LqALY-1YSOkB3taK-00dlpT; Thu, 13 Nov 2014 17:28:48 +0100 Message-ID: <5464DC39.4020703@gmx.at> Date: Thu, 13 Nov 2014 17:28:41 +0100 From: martin rudalics MIME-Version: 1.0 To: Drew Adams , 19012@debbugs.gnu.org Subject: Re: bug#19012: 25.0.50; `help-window-select' 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> <561951d1-fee4-44ea-bc22-d354b007601d@default> <54646172.7020801@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Dt2E63mWbNk6dyyGDcAyBLKtkY3Eu2uy9FYz5Ym1DDv800eLetu TegqT48HfAawzYr+8O3aNzsOOuiBw82dfcvHWwPvBjmlNWTQQ5yh9G4+qy1m2K5lGK1nQQX z8FCf6NNedY2DMXWcc0/kiO5YgHjNDeylAIY3fjEdda6xKnk/pha11t/vqek/iwsSysFOv7 PxjFtZLQG5p0JG3oMCm2g== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > I've been clear that (a) I do not want `raise-frame' to focus > frames, and that (b) whether I, as one user, want that behavior > or not, the behavior of that option should not affect whether > `help-window-select' works. So you want `raise-frame' to not select the frame and `with-help-window' select the frame? Any preferences who should win that game? > 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. martin From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 13 11:57:00 2014 Received: (at 19012) by debbugs.gnu.org; 13 Nov 2014 16:57:00 +0000 Received: from localhost ([127.0.0.1]:59579 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xoxhb-00020t-V5 for submit@debbugs.gnu.org; Thu, 13 Nov 2014 11:57:00 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:19091) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xoxha-00020l-3R for 19012@debbugs.gnu.org; Thu, 13 Nov 2014 11:56:58 -0500 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 sADGutkW013622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Nov 2014 16:56:56 GMT 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 sADGusx3001485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Nov 2014 16:56:55 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sADGusDX026901; Thu, 13 Nov 2014 16:56:54 GMT MIME-Version: 1.0 Message-ID: Date: Thu, 13 Nov 2014 08:56:53 -0800 (PST) From: Drew Adams To: martin rudalics , 19012@debbugs.gnu.org Subject: RE: bug#19012: 25.0.50; `help-window-select' 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> <561951d1-fee4-44ea-bc22-d354b007601d@default> <54646172.7020801@gmx.at> <5464DC39.4020703@gmx.at> In-Reply-To: <5464DC39.4020703@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -3.3 (---) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > I've been clear that (a) I do not want `raise-frame' to focus > > frames, and that (b) whether I, as one user, want that behavior > > or not, the behavior of that option should not affect whether > > `help-window-select' works. >=20 > 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. But even if it did, that should be irrelevant to what `help-select-window' does (*this* bug). `raise-frame' is punctual. 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). 2. `help-window-select' =3D `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. 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. > > 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. >=20 > So far you did not provide any evidence that the window is not > selected. Sure I did. 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. 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. 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 13 13:48:04 2014 Received: (at 19012) by debbugs.gnu.org; 13 Nov 2014 18:48:04 +0000 Received: from localhost ([127.0.0.1]:59695 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XozR5-0007Xy-Lx for submit@debbugs.gnu.org; Thu, 13 Nov 2014 13:48:04 -0500 Received: from mout.gmx.net ([212.227.15.15]:63801) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XozR2-0007XX-Kc for 19012@debbugs.gnu.org; Thu, 13 Nov 2014 13:48:01 -0500 Received: from [91.113.3.148] ([91.113.3.148]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M8ehf-1YBamm023H-00wGN0; Thu, 13 Nov 2014 19:47:55 +0100 Message-ID: <5464FCD5.6070201@gmx.at> Date: Thu, 13 Nov 2014 19:47:49 +0100 From: martin rudalics MIME-Version: 1.0 To: Drew Adams , 19012@debbugs.gnu.org Subject: Re: bug#19012: 25.0.50; `help-window-select' 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> <561951d1-fee4-44ea-bc22-d354b007601d@default> <54646172.7020801@gmx.at> <5464DC39.4020703@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:M0qC/dryJILH26gFp4zFy7Nu8HGL35NJ2tNoJWkfIrZY8JH5W6t jZ2k9yJw+25cNXsoH7Xf6yVfMJWtpD4+ImLL640iPcB059dauen7Wwl4n9RsdME8U7cRvYs RtxYjUWRMVz5C/Rvxr5QdXwz/S3U+q0Jfhvxk2gpS6unS7m7fpdYEtMqvOe/L6vjnXSCi5I z4+9EBnL69MrAxviWvM0A== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) >> 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 13 14:21:37 2014 Received: (at 19012) by debbugs.gnu.org; 13 Nov 2014 19:21:37 +0000 Received: from localhost ([127.0.0.1]:59720 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XozxY-0008R0-Q5 for submit@debbugs.gnu.org; Thu, 13 Nov 2014 14:21:37 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:43687) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XozxV-0008Qo-Oe for 19012@debbugs.gnu.org; Thu, 13 Nov 2014 14:21:34 -0500 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 sADJLU86015611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Nov 2014 19:21:32 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sADJLTqF020439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Nov 2014 19:21:29 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sADJLS4o020418; Thu, 13 Nov 2014 19:21:29 GMT MIME-Version: 1.0 Message-ID: <66cb622a-236c-4e8d-a7ba-cb1de310bb05@default> Date: Thu, 13 Nov 2014 11:21:28 -0800 (PST) From: Drew Adams To: martin rudalics , 19012@debbugs.gnu.org Subject: RE: bug#19012: 25.0.50; `help-window-select' 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> <561951d1-fee4-44ea-bc22-d354b007601d@default> <54646172.7020801@gmx.at> <5464DC39.4020703@gmx.at> <5464FCD5.6070201@gmx.at> In-Reply-To: <5464FCD5.6070201@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -3.3 (---) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > 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. >=20 > 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. >=20 > > But even if it did, that should be irrelevant to what > > `help-select-window' does (*this* bug). >=20 > What is "*this* bug"? You attribute a behavior you observe to a > variable that does not and cannot control that behavior. Bug 19012. As you admitted, if `help-window-select' is t, it is a bug if `with-help-window' exits with the window not selected. =20 > > `raise-frame' is punctual. >=20 > I have no idea what you mean here. It takes place at a moment in time. `with-help-window' has an effect for a duration/scope. `with-help-window', with `help-window-select' =3D t, should ensure that the window is selected when it is finished. > > 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). >=20 > Scope and effect of `help-window-select' end where `with-help- > window' exits. Precisely. And not before. If Emacs is fixed so that `with-help-window' ensures that the window is selected when it exits (with non-nil `help-window-select') then this bug (#19012) can be closed. > > 2. `help-window-select' =3D `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. >=20 > If `help-window-select' is t, `with-help-window' selects the frame > unconditionally. Great. Does it ensure that it is selected when it is finished? It seems that that is not the case yet. AFAICT (from the info you've provided), that is the cause of the bugged behavior. > > 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. >=20 > Doesn't it? Apparently not. The window is not selected/focused. (And the `raise-frame' is called within `with-help-window', not after `with-help-window' is finished. > >> > 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. >=20 > You didn't even care to go through this with a debugger. What kind > of evidence is that? Dunno what that means. If you have some recipe you'd like me to follow, I'll see if I can try it. > > 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. >=20 > This does not contradict that `with-help-window' selected the > window. I think it contradicts the expectation that `with-help-window' ensures that the window is selected when it finishes. After it finishes, it of course has no more responsibility wrt whether it is selected. > > 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. >=20 > 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. Yes, I don't want to get involved with the implementation or trying to fix the problem. I am willing to report the problem and try to obtain more info about symptoms. > There is absolutely nothing `with-help-window' or any Elisp code > can do there. I never said there was. Perhaps that is the communication problem here. I never said that you are responsible for the bug or for fixing it. And I never said that the bug is due to Elisp code. (In fact, since I discovered that it is nil `w32-*' that leads to the bug, I've been supposing that the problem involves C code.) > > 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. >=20 > You can't have both - select the frame and unfocus it. I'm not asking to unfocus the frame. I'm asking that `with-help-window' ensure that, when it exits, the window is selected and the frame focused. And that, regardless of whether some code within its scope happens to focus some other frame at some point. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 14 06:37:25 2014 Received: (at 19012) by debbugs.gnu.org; 14 Nov 2014 11:37:25 +0000 Received: from localhost ([127.0.0.1]:60235 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XpFBs-0006vt-Qh for submit@debbugs.gnu.org; Fri, 14 Nov 2014 06:37:25 -0500 Received: from mout.gmx.net ([212.227.17.21]:64948) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XpFBq-0006vi-Lv for 19012@debbugs.gnu.org; Fri, 14 Nov 2014 06:37:23 -0500 Received: from [88.117.119.30] ([88.117.119.30]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LxLcc-1Y4xmh1bMQ-016vWB; Fri, 14 Nov 2014 12:37:17 +0100 Message-ID: <5465E967.1050304@gmx.at> Date: Fri, 14 Nov 2014 12:37:11 +0100 From: martin rudalics MIME-Version: 1.0 To: Drew Adams , 19012@debbugs.gnu.org Subject: Re: bug#19012: 25.0.50; `help-window-select' 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> <561951d1-fee4-44ea-bc22-d354b007601d@default> <54646172.7020801@gmx.at> <5464DC39.4020703@gmx.at> <5464FCD5.6070201@gmx.at> <66cb622a-236c-4e8d-a7ba-cb1de310bb05@default> In-Reply-To: <66cb622a-236c-4e8d-a7ba-cb1de310bb05@default> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:2ZK0wHZEuox9MErBpaJFLAIaPs/KtJtjUWvLgiOvg9E6NXL5rTo hmR0qPqSbliXhe/hD+cAdZhPx78coffUihGQdVc1mDi7rwvzQOARMC/yiL1PCt/Jpf70zhc LSE48PJb/YxmWFIdLgbcUwbP33hG3mOgfEW5OlFLHwJ8tM2IQrZxWiGizP7wWx1ZpvT1ecJ +jVgmnFeNIHWEB/fN8vWw== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) >> What is "*this* bug"? You attribute a behavior you observe to a >> variable that does not and cannot control that behavior. > > Bug 19012. Then give us a recipe so we can reproduce that "bug". Sections 51.3 "Understanding Bug Reporting" and 51.4 "Checklist for Bug Reports" of the Emacs manual will give you further guidance. Here with emacs -Q and evaluating (setq pop-up-frames t) (setq w32-grab-focus-on-raise nil) (setq help-window-select t) (defun 1on1-display-*Help*-frame (buf &optional args) "Display *Help* buffer in its own frame. `special-display-function' is used to do the actual displaying. BUF and ARGS are the arguments to `special-display-function'." (let ((old-ptr-shape (and (boundp 'x-pointer-shape) x-pointer-shape)) return-window) (when (boundp 'x-pointer-xterm) (setq x-pointer-shape x-pointer-xterm)) (setq return-window (select-window (funcall special-display-function buf args))) (raise-frame) (setq x-pointer-shape old-ptr-shape) return-window)) (add-to-list 'special-display-buffer-names (list "*Help*" '1on1-display-*Help*-frame (list '(height . 40)))) both C-h f and C-h v select the window showing *Help*. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 14 10:11:43 2014 Received: (at 19012) by debbugs.gnu.org; 14 Nov 2014 15:11:43 +0000 Received: from localhost ([127.0.0.1]:60862 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XpIXH-0008B5-3a for submit@debbugs.gnu.org; Fri, 14 Nov 2014 10:11:43 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:35060) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XpIXE-0008Ar-T0 for 19012@debbugs.gnu.org; Fri, 14 Nov 2014 10:11:41 -0500 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sAEFBdQX018923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Nov 2014 15:11:40 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAEFBc4o011148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Nov 2014 15:11:38 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id sAEFBb8u017917; Fri, 14 Nov 2014 15:11:38 GMT MIME-Version: 1.0 Message-ID: <41926108-7556-4b72-ae2c-60933b4ff187@default> Date: Fri, 14 Nov 2014 07:11:37 -0800 (PST) From: Drew Adams To: martin rudalics , 19012@debbugs.gnu.org Subject: RE: bug#19012: 25.0.50; `help-window-select' 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> <561951d1-fee4-44ea-bc22-d354b007601d@default> <54646172.7020801@gmx.at> <5464DC39.4020703@gmx.at> <5464FCD5.6070201@gmx.at> <66cb622a-236c-4e8d-a7ba-cb1de310bb05@default> <5465E967.1050304@gmx.at> In-Reply-To: <5465E967.1050304@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > Then give us a recipe so we can reproduce that "bug".... > Here with emacs -Q and evaluating... > both C-h f and C-h v select the window showing *Help*. Why do you not try the even simpler recipe I sent on 2014-11-12? You clearly read that mail, as you replied to other parts of it. With the latest Emacs build I have (and with others) the recipe is 100% reproducible. I am using MS Windows 7 64-bit. In GNU Emacs 25.0.50.1 (i686-pc-mingw32) of 2014-10-20 on LEG570 Repository revision: 118168 rgm@gnu.org-20141020195941-icp42t8ttcnud09g Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --enable-checking=3Dyes,glyphs CPPFLAGS=3D-DGLYPH_DEBUG=3D1' Here is the recipe again: 1. emacs -Q 2. Evaluate the code shown below (after recipe #5). 3. 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. 4. Select the original frame (e.g. with the mouse), so that it, not *Help*, now has the focus. 5. C-h v help-window-select RET The *Help* window & frame are not selected/focused. They should be. The code to evaluate at step #2 above: (setq pop-up-frames t) (setq help-window-select t) (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)) From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 14 11:38:55 2014 Received: (at 19012) by debbugs.gnu.org; 14 Nov 2014 16:38:55 +0000 Received: from localhost ([127.0.0.1]:60997 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XpJtf-0004jr-2X for submit@debbugs.gnu.org; Fri, 14 Nov 2014 11:38:55 -0500 Received: from mout.gmx.net ([212.227.17.20]:60818) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XpJtd-0004ji-8E for 19012@debbugs.gnu.org; Fri, 14 Nov 2014 11:38:54 -0500 Received: from [62.47.141.44] ([62.47.141.44]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MZU7V-1XZB9d15DR-00LBRQ; Fri, 14 Nov 2014 17:38:45 +0100 Message-ID: <5466300D.2030708@gmx.at> Date: Fri, 14 Nov 2014 17:38:37 +0100 From: martin rudalics MIME-Version: 1.0 To: Drew Adams , 19012@debbugs.gnu.org Subject: Re: bug#19012: 25.0.50; `help-window-select' 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> <561951d1-fee4-44ea-bc22-d354b007601d@default> <54646172.7020801@gmx.at> <5464DC39.4020703@gmx.at> <5464FCD5.6070201@gmx.at> <66cb622a-236c-4e8d-a7ba-cb1de310bb05@default> <5465E967.1050304@gmx.at> <41926108-7556-4b72-ae2c-60933b4ff187@default> In-Reply-To: <41926108-7556-4b72-ae2c-60933b4ff187@default> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:HsqUjfIsbMcAmNj/L60HWBeTnL+MwKm99lovVNYtIqnE4BxfSid YRu/Zr+QMNT8sWDVlSE82QV0QbwnsTnfhbdGv6gJ/OYFPHDoNN2KDCHeEt8xKvsXcA5B/Ub ZoaENMdEeJaK87dYhuexAxxKpKy65weJLFt/QQZflpQOa75uoUTSDKvNYWFiUHuOtvS0Q8I RsOCu4j9/IgIY4XeU55Zg== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > With the latest Emacs build I have (and with others) the recipe > is 100% reproducible. I am using MS Windows 7 64-bit. Maybe a Windows 7 issue. > 1. emacs -Q > 2. Evaluate the code shown below (after recipe #5). > 3. 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. > 4. Select the original frame (e.g. with the mouse), so that > it, not *Help*, now has the focus. > 5. C-h v help-window-select RET > The *Help* window & frame are not selected/focused. > They should be. > > The code to evaluate at step #2 above: > (setq pop-up-frames t) > (setq help-window-select t) > (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)) Unreproducible here. After 5 the *Help* frame has focus again. Sorry. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 14 12:09:14 2014 Received: (at 19012) by debbugs.gnu.org; 14 Nov 2014 17:09:14 +0000 Received: from localhost ([127.0.0.1]:32806 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XpKN0-0005Zh-05 for submit@debbugs.gnu.org; Fri, 14 Nov 2014 12:09:14 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:43911) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XpKMy-0005ZZ-AM for 19012@debbugs.gnu.org; Fri, 14 Nov 2014 12:09:12 -0500 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 sAEH9A4N018259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Nov 2014 17:09:11 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAEH99cH019278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Nov 2014 17:09:09 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id sAEH98E7027068; Fri, 14 Nov 2014 17:09:08 GMT MIME-Version: 1.0 Message-ID: <75786231-f3a3-420f-a0d8-4960e09c720e@default> Date: Fri, 14 Nov 2014 09:09:07 -0800 (PST) From: Drew Adams To: martin rudalics , 19012@debbugs.gnu.org Subject: RE: bug#19012: 25.0.50; `help-window-select' 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> <561951d1-fee4-44ea-bc22-d354b007601d@default> <54646172.7020801@gmx.at> <5464DC39.4020703@gmx.at> <5464FCD5.6070201@gmx.at> <66cb622a-236c-4e8d-a7ba-cb1de310bb05@default> <5465E967.1050304@gmx.at> <41926108-7556-4b72-ae2c-60933b4ff187@default> <5466300D.2030708@gmx.at> In-Reply-To: <5466300D.2030708@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > > With the latest Emacs build I have (and with others) the recipe > > is 100% reproducible. I am using MS Windows 7 64-bit. >=20 > Maybe a Windows 7 issue. I can't swear to it, but I think that I saw the same thing when I was on Windows XP (32-bit). That was more than a year ago so I might not remember correctly. > Unreproducible here. After 5 the *Help* frame has focus again. > Sorry. Thanks for checking. Hopefully someone else can check on Windows 7 64-bit. (I assume that you checked the focus by typing some text or something. Here, the text is inserted in the buffer when I hit `C-h v'.) From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 14 12:40:14 2014 Received: (at 19012) by debbugs.gnu.org; 14 Nov 2014 17:40:14 +0000 Received: from localhost ([127.0.0.1]:32829 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XpKr0-0006W1-5j for submit@debbugs.gnu.org; Fri, 14 Nov 2014 12:40:14 -0500 Received: from mout.gmx.net ([212.227.17.20]:54023) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XpKqw-0006Vq-My for 19012@debbugs.gnu.org; Fri, 14 Nov 2014 12:40:12 -0500 Received: from [62.47.141.44] ([62.47.141.44]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LfYqz-1YMgeO09RB-00p8bH; Fri, 14 Nov 2014 18:40:09 +0100 Message-ID: <54663E6F.6010702@gmx.at> Date: Fri, 14 Nov 2014 18:39:59 +0100 From: martin rudalics MIME-Version: 1.0 To: Drew Adams , 19012@debbugs.gnu.org Subject: Re: bug#19012: 25.0.50; `help-window-select' 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> <561951d1-fee4-44ea-bc22-d354b007601d@default> <54646172.7020801@gmx.at> <5464DC39.4020703@gmx.at> <5464FCD5.6070201@gmx.at> <66cb622a-236c-4e8d-a7ba-cb1de310bb05@default> <5465E967.1050304@gmx.at> <41926108-7556-4b72-ae2c-60933b4ff187@default> <5466300D.2030708@gmx.at> <75786231-f3a3-420f-a0d8-4960e09c720e@default> In-Reply-To: <75786231-f3a3-420f-a0d8-4960e09c720e@default> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:sFc6xiR1DCaGoQIRGmsM4Ovn5esPs/i/c0M4l94Q42IMZObrUOU D9j2LDeB6Nh6pDTw723eRYHKGYIq5NGSWcNDY736WymjivkdHsD2dGsWpoFWIbq0xfWn04U FfmPgLdhW5zR+0HUKQJ5tGZ+PC7EI9CFdd75n+vQBW63Cpv8gVOqW92dvmQtB9NO/pS4EsY v6hRVd3o/Sfso4zRMVu+A== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > Thanks for checking. Hopefully someone else can check on > Windows 7 64-bit. Do the following: With emacs -Q eval the code below in *scratch*. Next do 1. M-x view-lossage 2. Go back to the *scratch* window. 3. M-x view-lossage 4. In the *scratch* window move to the line that reads (defvar selected-window nil), move right after selected-window, type C-x C-e. Here I get #. What do you get? martin (defvar selected-window nil) (setq pop-up-frames t) (setq help-window-select t) (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)) (defun view-lossage () "Display last few input keystrokes and the commands run. To record all your input, use `open-dribble-file'." (interactive) (help-setup-xref (list #'view-lossage) (called-interactively-p 'interactive)) (with-help-window (help-buffer) (princ " ") (princ (mapconcat (lambda (key) (cond ((and (consp key) (null (car key))) (format "[%s]\n" (if (symbolp (cdr key)) (cdr key) "anonymous-command"))) ((or (integerp key) (symbolp key) (listp key)) (single-key-description key)) (t (prin1-to-string key nil)))) (recent-keys 'include-cmds) " ")) (with-current-buffer standard-output (goto-char (point-min)) (while (not (eobp)) (move-to-column 50) (unless (eolp) (fill-region (line-beginning-position) (line-end-position))) (forward-line 1)) ;; jidanni wants to see the last keystrokes immediately. (set-marker help-window-point-marker (point)))) (setq selected-window (selected-window))) From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 14 12:47:10 2014 Received: (at 19012) by debbugs.gnu.org; 14 Nov 2014 17:47:10 +0000 Received: from localhost ([127.0.0.1]:32833 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XpKxi-0006gx-40 for submit@debbugs.gnu.org; Fri, 14 Nov 2014 12:47:10 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:29707) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XpKxg-0006gp-4U for 19012@debbugs.gnu.org; Fri, 14 Nov 2014 12:47:08 -0500 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sAEHl663032510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Nov 2014 17:47:07 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAEHl5FC003369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Nov 2014 17:47:05 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAEHl4ZJ003348; Fri, 14 Nov 2014 17:47:04 GMT MIME-Version: 1.0 Message-ID: <5453eef4-1955-4b79-819a-43786f56a8cc@default> Date: Fri, 14 Nov 2014 09:47:04 -0800 (PST) From: Drew Adams To: martin rudalics , 19012@debbugs.gnu.org Subject: RE: bug#19012: 25.0.50; `help-window-select' 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> <561951d1-fee4-44ea-bc22-d354b007601d@default> <54646172.7020801@gmx.at> <5464DC39.4020703@gmx.at> <5464FCD5.6070201@gmx.at> <66cb622a-236c-4e8d-a7ba-cb1de310bb05@default> <5465E967.1050304@gmx.at> <41926108-7556-4b72-ae2c-60933b4ff187@default> <5466300D.2030708@gmx.at> <75786231-f3a3-420f-a0d8-4960e09c720e@default> <54663E6F.6010702@gmx.at> In-Reply-To: <54663E6F.6010702@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > Do the following: With emacs -Q eval the code below in *scratch*. Did that. > Next do >=20 > 1. M-x view-lossage I got this error: Wrong number of arguments: recent-keys, 1 `C-h f recent-keys' shows that it accepts no args. Will try again after you update the code to use, if appropriate. Thanks for taking a look. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 14 13:10:20 2014 Received: (at 19012) by debbugs.gnu.org; 14 Nov 2014 18:10:20 +0000 Received: from localhost ([127.0.0.1]:32838 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XpLK8-0007Gr-1r for submit@debbugs.gnu.org; Fri, 14 Nov 2014 13:10:20 -0500 Received: from mout.gmx.net ([212.227.17.22]:62078) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XpLK4-0007Gh-HN for 19012@debbugs.gnu.org; Fri, 14 Nov 2014 13:10:17 -0500 Received: from [93.82.11.4] ([93.82.11.4]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LhjeH-1YKbTy0tqz-00muj0; Fri, 14 Nov 2014 19:10:15 +0100 Message-ID: <5466457F.8000400@gmx.at> Date: Fri, 14 Nov 2014 19:10:07 +0100 From: martin rudalics MIME-Version: 1.0 To: Drew Adams , 19012@debbugs.gnu.org Subject: Re: bug#19012: 25.0.50; `help-window-select' 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> <561951d1-fee4-44ea-bc22-d354b007601d@default> <54646172.7020801@gmx.at> <5464DC39.4020703@gmx.at> <5464FCD5.6070201@gmx.at> <66cb622a-236c-4e8d-a7ba-cb1de310bb05@default> <5465E967.1050304@gmx.at> <41926108-7556-4b72-ae2c-60933b4ff187@default> <5466300D.2030708@gmx.at> <75786231-f3a3-420f-a0d8-4960e09c720e@default> <54663E6F.6010702@gmx.at> <5453eef4-1955-4b79-819a-43786f56a8cc@default> In-Reply-To: <5453eef4-1955-4b79-819a-43786f56a8cc@default> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:P1JObl6jsPXQNeIewOi9fXzpNfQj8Eg4M/eIypVxnxfri1d2edb MKlSbYeYEZsZiqgqaeZ91WvaESjaNjOaG8FvEAsENUuqN9wAJoGzKhmT6uIa4/xXcC0NXOd q0EzW/InVl3T3dqX0qm4qURYi06btl5LlkVdexILernlUTS9hK8uE6wNe22TvHsIOKGr9zH cexM+J+GYv5H3+m+iiEBA== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > Will try again after you update the code to use, if appropriate. OK. Please try the below. martin (defvar selected-window nil) (setq pop-up-frames t) (setq help-window-select t) (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)) (defun view-lossage () "Display last 300 input keystrokes. To record all your input, use `open-dribble-file'." (interactive) (help-setup-xref (list #'view-lossage) (called-interactively-p 'interactive)) (with-help-window (help-buffer) (princ (mapconcat (lambda (key) (if (or (integerp key) (symbolp key) (listp key)) (single-key-description key) (prin1-to-string key nil))) (recent-keys) " ")) (with-current-buffer standard-output (goto-char (point-min)) (while (progn (move-to-column 50) (not (eobp))) (when (search-forward " " nil t) (delete-char -1)) (insert "\n")) ;; jidanni wants to see the last keystrokes immediately. (set-marker help-window-point-marker (point)))) (setq selected-window (selected-window))) From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 14 13:28:39 2014 Received: (at 19012) by debbugs.gnu.org; 14 Nov 2014 18:28:39 +0000 Received: from localhost ([127.0.0.1]:32847 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XpLbq-0007jc-RQ for submit@debbugs.gnu.org; Fri, 14 Nov 2014 13:28:39 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:17445) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XpLbo-0007jU-T7 for 19012@debbugs.gnu.org; Fri, 14 Nov 2014 13:28:37 -0500 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sAEISZDS018285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Nov 2014 18:28:35 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id sAEISYWR011074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Nov 2014 18:28:34 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAEISY2x006281; Fri, 14 Nov 2014 18:28:34 GMT MIME-Version: 1.0 Message-ID: Date: Fri, 14 Nov 2014 10:28:33 -0800 (PST) From: Drew Adams To: martin rudalics , 19012@debbugs.gnu.org Subject: RE: bug#19012: 25.0.50; `help-window-select' 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> <561951d1-fee4-44ea-bc22-d354b007601d@default> <54646172.7020801@gmx.at> <5464DC39.4020703@gmx.at> <5464FCD5.6070201@gmx.at> <66cb622a-236c-4e8d-a7ba-cb1de310bb05@default> <5465E967.1050304@gmx.at> <41926108-7556-4b72-ae2c-60933b4ff187@default> <5466300D.2030708@gmx.at> <75786231-f3a3-420f-a0d8-4960e09c720e@default> <54663E6F.6010702@gmx.at> <5453eef4-1955-4b79-819a-43786f56a8cc@default> <5466457F.8000400@gmx.at> In-Reply-To: <5466457F.8000400@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) I too see the message "#". However, if I type text it is inserted in buffer *scratch*. And the *Help* frame border indicates that it is not the current/focused/selected frame. So apparently the frame is not focused, even if the window is selected. HTH. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 14 13:33:40 2014 Received: (at 19012) by debbugs.gnu.org; 14 Nov 2014 18:33:41 +0000 Received: from localhost ([127.0.0.1]:32851 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XpLgi-0007sr-LP for submit@debbugs.gnu.org; Fri, 14 Nov 2014 13:33:40 -0500 Received: from mout.gmx.net ([212.227.17.22]:60594) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XpLgh-0007sj-5A for 19012@debbugs.gnu.org; Fri, 14 Nov 2014 13:33:40 -0500 Received: from [93.82.11.4] ([93.82.11.4]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Ldttv-1YFdsd0mvL-00j5KE; Fri, 14 Nov 2014 19:33:32 +0100 Message-ID: <54664AF4.9000606@gmx.at> Date: Fri, 14 Nov 2014 19:33:24 +0100 From: martin rudalics MIME-Version: 1.0 To: Drew Adams , 19012@debbugs.gnu.org Subject: Re: bug#19012: 25.0.50; `help-window-select' 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> <561951d1-fee4-44ea-bc22-d354b007601d@default> <54646172.7020801@gmx.at> <5464DC39.4020703@gmx.at> <5464FCD5.6070201@gmx.at> <66cb622a-236c-4e8d-a7ba-cb1de310bb05@default> <5465E967.1050304@gmx.at> <41926108-7556-4b72-ae2c-60933b4ff187@default> <5466300D.2030708@gmx.at> <75786231-f3a3-420f-a0d8-4960e09c720e@default> <54663E6F.6010702@gmx.at> <5453eef4-1955-4b79-819a-43786f56a8cc@default> <5466457F.8000400@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:l268q6WkNqNL5hMVnyjiK2Xj+eo2qKH9OuXrW24YWchbE9Qu0OO vY8fcPD4pxaOFNy1wh+VojAblKPABazOVj+HmIhanll4LEPEvUujLjf5avA7LA0MEldnexM 0otB7WqvRoL5u5v189Ya98bbE1jZlLFE1rF/PBqZHhoMKFKIVBDEGZqNzDdgAtJySVqXZ0a ILF2eH6LJMbhOI0OGTYpw== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > I too see the message "#". > > However, if I type text it is inserted in buffer *scratch*. > And the *Help* frame border indicates that it is not the > current/focused/selected frame. > > So apparently the frame is not focused, even if the window is > selected. HTH. What does evaluating (selected-window) give when the *Help* frame is raised while the *scratch* frame is focused? martin From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 14 13:44:18 2014 Received: (at 19012) by debbugs.gnu.org; 14 Nov 2014 18:44:18 +0000 Received: from localhost ([127.0.0.1]:32855 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XpLqz-000897-Ps for submit@debbugs.gnu.org; Fri, 14 Nov 2014 13:44:18 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:25542) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XpLqt-00088v-HM for 19012@debbugs.gnu.org; Fri, 14 Nov 2014 13:44:15 -0500 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sAEIi9t6004248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Nov 2014 18:44:10 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAEIi72K028393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Nov 2014 18:44:08 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAEIi7cm001367; Fri, 14 Nov 2014 18:44:07 GMT MIME-Version: 1.0 Message-ID: <97868572-923b-4f0a-bd16-b4d475ddb002@default> Date: Fri, 14 Nov 2014 10:44:06 -0800 (PST) From: Drew Adams To: martin rudalics , 19012@debbugs.gnu.org Subject: RE: bug#19012: 25.0.50; `help-window-select' 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> <561951d1-fee4-44ea-bc22-d354b007601d@default> <54646172.7020801@gmx.at> <5464DC39.4020703@gmx.at> <5464FCD5.6070201@gmx.at> <66cb622a-236c-4e8d-a7ba-cb1de310bb05@default> <5465E967.1050304@gmx.at> <41926108-7556-4b72-ae2c-60933b4ff187@default> <5466300D.2030708@gmx.at> <75786231-f3a3-420f-a0d8-4960e09c720e@default> <54663E6F.6010702@gmx.at> <5453eef4-1955-4b79-819a-43786f56a8cc@default> <5466457F.8000400@gmx.at> <54664AF4.9000606@gmx.at> In-Reply-To: <54664AF4.9000606@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > > I too see the message "#". > > > > However, if I type text it is inserted in buffer *scratch*. > > And the *Help* frame border indicates that it is not the > > current/focused/selected frame. > > > > So apparently the frame is not focused, even if the window is > > selected. HTH. >=20 > What does evaluating (selected-window) give when the *Help* frame is > raised while the *scratch* frame is focused? `M-: (selected-window)' at that point shows: # From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 14 14:08:43 2014 Received: (at 19012) by debbugs.gnu.org; 14 Nov 2014 19:08:43 +0000 Received: from localhost ([127.0.0.1]:32871 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XpMEd-0000JT-2G for submit@debbugs.gnu.org; Fri, 14 Nov 2014 14:08:43 -0500 Received: from mout.gmx.net ([212.227.17.21]:51314) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XpMEa-0000JJ-2F for 19012@debbugs.gnu.org; Fri, 14 Nov 2014 14:08:41 -0500 Received: from [93.82.11.4] ([93.82.11.4]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Ld4xA-1YFvbo0dbE-00iGB4; Fri, 14 Nov 2014 20:08:36 +0100 Message-ID: <5466532C.2040003@gmx.at> Date: Fri, 14 Nov 2014 20:08:28 +0100 From: martin rudalics MIME-Version: 1.0 To: Drew Adams , 19012@debbugs.gnu.org Subject: Re: bug#19012: 25.0.50; `help-window-select' 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> <561951d1-fee4-44ea-bc22-d354b007601d@default> <54646172.7020801@gmx.at> <5464DC39.4020703@gmx.at> <5464FCD5.6070201@gmx.at> <66cb622a-236c-4e8d-a7ba-cb1de310bb05@default> <5465E967.1050304@gmx.at> <41926108-7556-4b72-ae2c-60933b4ff187@default> <5466300D.2030708@gmx.at> <75786231-f3a3-420f-a0d8-4960e09c720e@default> <54663E6F.6010702@gmx.at> <5453eef4-1955-4b79-819a-43786f56a8cc@default> <5466457F.8000400@gmx.at> <54664AF4.9000606@gmx.at> <97868572-923b-4f0a-bd16-b4d475ddb002@default> In-Reply-To: <97868572-923b-4f0a-bd16-b4d475ddb002@default> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:UetBh7Ze0YcbqDZdxhib1EpnwqhJpnR0KvgbV5RLS/y1XW1wHlN FgahxTvFySlb+TePd4Ou0q60Fz+JjhuF6jMEniozBiSHgIlPDSnF9eCo3Cs7ByPpf7PyVO5 EUdM6HkjmcQwsrMz1V9O10cSRSqDcDDQM7I1StWpvSSteerGfp9Fw/R+D9l+k7X/V0U3TDF tJQm5kgapOW/qAJtl6Vsw== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) >> > I too see the message "#". >> > >> > However, if I type text it is inserted in buffer *scratch*. >> > And the *Help* frame border indicates that it is not the >> > current/focused/selected frame. >> > >> > So apparently the frame is not focused, even if the window is >> > selected. HTH. >> >> What does evaluating (selected-window) give when the *Help* frame is >> raised while the *scratch* frame is focused? > > `M-: (selected-window)' at that point shows: # Together this proves two things: (1) `with-help-window' correctly selects the *Help* window. (2) `raise-frame' is far from "punctual" (takes place at a moment in time) as you claimed earlier. You can try the following: In `temp-buffer-window-setup-hook' set `w32-grab-focus-on-raise' to t. In `temp-buffer-window-show-hook' set it back to nil. Meanwhile I seem to understand why I can't see the behavior you describe on my Windows XP. I have both "Activation follows mouse" and "Autoraise when activating" set. So apparently when the second frame is raised my mouse moves there and focuses the frame. This means that the rigmarole done by `w32-grab-focus-on-raise' nil has no effect here at all. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 14 16:21:25 2014 Received: (at 19012) by debbugs.gnu.org; 14 Nov 2014 21:21:26 +0000 Received: from localhost ([127.0.0.1]:32910 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XpOJ3-0003hd-FX for submit@debbugs.gnu.org; Fri, 14 Nov 2014 16:21:25 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:33543) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XpOJ1-0003hV-Jd for 19012@debbugs.gnu.org; Fri, 14 Nov 2014 16:21:24 -0500 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sAELLLxp020237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Nov 2014 21:21:21 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAELLKjw003243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Nov 2014 21:21:20 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id sAELLJrd027631; Fri, 14 Nov 2014 21:21:20 GMT MIME-Version: 1.0 Message-ID: <2b53c981-eaef-47f3-850a-6367b4cd5dc1@default> Date: Fri, 14 Nov 2014 13:21:18 -0800 (PST) From: Drew Adams To: martin rudalics , 19012@debbugs.gnu.org Subject: RE: bug#19012: 25.0.50; `help-window-select' 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> <561951d1-fee4-44ea-bc22-d354b007601d@default> <54646172.7020801@gmx.at> <5464DC39.4020703@gmx.at> <5464FCD5.6070201@gmx.at> <66cb622a-236c-4e8d-a7ba-cb1de310bb05@default> <5465E967.1050304@gmx.at> <41926108-7556-4b72-ae2c-60933b4ff187@default> <5466300D.2030708@gmx.at> <75786231-f3a3-420f-a0d8-4960e09c720e@default> <54663E6F.6010702@gmx.at> <5453eef4-1955-4b79-819a-43786f56a8cc@default> <5466457F.8000400@gmx.at> <54664AF4.9000606@gmx.at> <97868572-923b-4f0a-bd16-b4d475ddb002@default> <5466532C.2040003@gmx.at> In-Reply-To: <5466532C.2040003@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > >> What does evaluating (selected-window) give when the *Help* > >> frame is raised while the *scratch* frame is focused? > > > > `M-: (selected-window)' at that point shows: > > # >=20 > Together this proves two things: >=20 > (1) `with-help-window' correctly selects the *Help* window. > (2) `raise-frame' is far from "punctual" (takes place at a moment in > time) as you claimed earlier. I won't argue about what it proves. (I don't see how it proves #2, but whatever.) It might indicate only that `raise-frame' does not necessarily do its "punctual" thing (raise the frame) exactly when it is called, synchronously. IOW, it might do that at some later time, asynchronously. Dunno. My point about the interaction between `raise-frame' and `with-help-window' was that the latter should try to ensure that the window is selected when it *ends*, not at some earlier point. But if `raise-frame' effectively does its thing *after* `with-help-window' ends, even if called from within `w-h-w', then that macro has no way to ensure selection after the actual effect of `raise-frame'. We can at least try to make sure that `w-h-w' selects the window at the very end. Of course, `w-h-w' should not affect selection for calls to `raise-frame' (or other functions that select windows or focus) that happen after it is done. But if it can override any such selections that take place within its scope/duration, that is good. > You can try the following: In `temp-buffer-window-setup-hook' set > `w32-grab-focus-on-raise' to t. In `temp-buffer-window-show-hook' > set it back to nil. With the simple recipe I gave, that seems to fix things. Thanks. But: 1. The `temp-buffer-*-hook's are not only about showing *Help*. That workaround thus affects more than it should. 2. Users of `w32*' should not need to do that explicitly themselves. Perhaps Emacs can do the equivalent, itself (but limited to *Help*, not affecting all temp buffer display). > Meanwhile I seem to understand why I can't see the behavior you > describe on my Windows XP. I have both "Activation follows mouse" > and "Autoraise when activating" set. So apparently when the > second frame is raised my mouse moves there and focuses the frame. > This means that the rigmarole done by `w32-grab-focus-on-raise' > nil has no effect here at all. Dunno where those are set in Windows (I could google), but thanks for the info. (I do want the `w32*' effect, though.) From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 15 06:24:34 2014 Received: (at 19012) by debbugs.gnu.org; 15 Nov 2014 11:24:34 +0000 Received: from localhost ([127.0.0.1]:33295 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XpbSz-0007gz-Ni for submit@debbugs.gnu.org; Sat, 15 Nov 2014 06:24:34 -0500 Received: from mout.gmx.net ([212.227.15.18]:52733) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XpbSw-0007go-89 for 19012@debbugs.gnu.org; Sat, 15 Nov 2014 06:24:31 -0500 Received: from [178.190.161.208] ([178.190.161.208]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LbMmA-1YHlCa1J5m-00kz8B; Sat, 15 Nov 2014 12:24:26 +0100 Message-ID: <546737E1.6010406@gmx.at> Date: Sat, 15 Nov 2014 12:24:17 +0100 From: martin rudalics MIME-Version: 1.0 To: Drew Adams , 19012@debbugs.gnu.org Subject: Re: bug#19012: 25.0.50; `help-window-select' References: <5461C901.6060707@gmx.at> <3f833473-f246-4d57-95cd-2ac654d326c9@default> <5462561B.2030306@gmx.at> <561951d1-fee4-44ea-bc22-d354b007601d@default> <54646172.7020801@gmx.at> <5464DC39.4020703@gmx.at> <5464FCD5.6070201@gmx.at> <66cb622a-236c-4e8d-a7ba-cb1de310bb05@default> <5465E967.1050304@gmx.at> <41926108-7556-4b72-ae2c-60933b4ff187@default> <5466300D.2030708@gmx.at> <75786231-f3a3-420f-a0d8-4960e09c720e@default> <54663E6F.6010702@gmx.at> <5453eef4-1955-4b79-819a-43786f56a8cc@default> <5466457F.8000400@gmx.at> <54664AF4.9000606@gmx.at> <97868572-923b-4f0a-bd16-b4d475ddb002@default> <5466532C.2040003@gmx.at> <2b53c981-eaef-47f3-850a-6367b4cd5dc1@default> In-Reply-To: <2b53c981-eaef-47f3-850a-6367b4cd5dc1@default> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:TL+nwdsbjoWrEtMoUA78LTTAnpb8XZY80bOtfZ5NufKrxqTGDV4 9zZ/b5VCFT53NKnS4bQJbUVsbz35tm2p+zr9XQuPYqqY9EnIxE7zxoSL8taRn0Q7H6uNNH0 ymq3KnRKQv8YyVFzv0Agoszysy0AO0Z0TK9DvAa/m7Bo0vGq6KJiNJrEU4VZt7wLJXQfAlV DzNEhBq5J0CYwIDMW9GCg== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > 1. The `temp-buffer-*-hook's are not only about showing *Help*. > That workaround thus affects more than it should. `temp-buffer-window-setup-hook' is run with *Help* current. So you won't have any problems discriminating this special case. > 2. Users of `w32*' should not need to do that explicitly > themselves. Perhaps Emacs can do the equivalent, itself (but > limited to *Help*, not affecting all temp buffer display). I cannot possibly use a feature like `w32-grab-focus-on-raise' whose semantics I neither understand nor can reenact in my environment in the frame/window code of Emacs. But we could change `help-window-setup' as follows: (defun help-window-setup (window &optional value) "Set up help window WINDOW for `with-help-window'. WINDOW is the window used for displaying the help buffer. Return VALUE." (let* ((help-buffer (when (window-live-p window) (window-buffer window))) (help-setup (when (window-live-p window) (car (window-parameter window 'quit-restore))))) (when help-buffer ;; Handle `help-window-point-marker'. (when (eq (marker-buffer help-window-point-marker) help-buffer) (set-window-point window help-window-point-marker) ;; Reset `help-window-point-marker'. (set-marker help-window-point-marker nil)) (cond ((or (eq window (selected-window)) (and (or (eq help-window-select t) (eq help-setup 'frame) (and (eq help-window-select 'other) (eq (window-frame window) (selected-frame)) (> (length (window-list nil 'no-mini)) 2))) (select-window window))) (when help-window-select (select-frame-set-input-focus (window-frame window))) ;; The help window is or gets selected ... (help-window-display-message (cond ((eq help-setup 'window) ;; ... and is new, ... "Type \"q\" to delete help window") ((eq help-setup 'frame) "Type \"q\" to quit the help frame") ((eq help-setup 'other) ;; ... or displayed some other buffer before. "Type \"q\" to restore previous buffer")) window t)) ((and (eq (window-frame window) (selected-frame)) (= (length (window-list nil 'no-mini)) 2)) ;; There are two windows on the help window's frame and the ;; other one is the selected one. (help-window-display-message (cond ((eq help-setup 'window) "Type \\[delete-other-windows] to delete the help window") ((eq help-setup 'other) "Type \"q\" in help window to restore its previous buffer")) window 'other)) (t ;; The help window is not selected ... (help-window-display-message (cond ((eq help-setup 'window) ;; ... and is new, ... "Type \"q\" in help window to delete it") ((eq help-setup 'other) ;; ... or displayed some other buffer before. "Type \"q\" in help window to restore previous buffer")) window)))) ;; Return VALUE. value)) martin From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 15 09:40:45 2014 Received: (at 19012) by debbugs.gnu.org; 15 Nov 2014 14:40:45 +0000 Received: from localhost ([127.0.0.1]:33420 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XpeWp-0005UW-Al for submit@debbugs.gnu.org; Sat, 15 Nov 2014 09:40:44 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:29928) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XpeWj-0005UH-51 for 19012@debbugs.gnu.org; Sat, 15 Nov 2014 09:40:37 -0500 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sAFEeZfU010166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 15 Nov 2014 14:40:36 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAFEeYIa014079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 15 Nov 2014 14:40:34 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAFEeYXS028131; Sat, 15 Nov 2014 14:40:34 GMT MIME-Version: 1.0 Message-ID: Date: Sat, 15 Nov 2014 06:40:35 -0800 (PST) From: Drew Adams To: martin rudalics , 19012@debbugs.gnu.org Subject: RE: bug#19012: 25.0.50; `help-window-select' References: <5461C901.6060707@gmx.at> <3f833473-f246-4d57-95cd-2ac654d326c9@default> <5462561B.2030306@gmx.at> <561951d1-fee4-44ea-bc22-d354b007601d@default> <54646172.7020801@gmx.at> <5464DC39.4020703@gmx.at> <5464FCD5.6070201@gmx.at> <66cb622a-236c-4e8d-a7ba-cb1de310bb05@default> <5465E967.1050304@gmx.at> <41926108-7556-4b72-ae2c-60933b4ff187@default> <5466300D.2030708@gmx.at> <75786231-f3a3-420f-a0d8-4960e09c720e@default> <54663E6F.6010702@gmx.at> <5453eef4-1955-4b79-819a-43786f56a8cc@default> <5466457F.8000400@gmx.at> <54664AF4.9000606@gmx.at> <97868572-923b-4f0a-bd16-b4d475ddb002@default> <5466532C.2040003@gmx.at> <2b53c981-eaef-47f3-850a-6367b4cd5dc1@default> <546737E1.6010406@gmx.at> In-Reply-To: <546737E1.6010406@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > > 1. The `temp-buffer-*-hook's are not only about showing *Help*. > > That workaround thus affects more than it should. >=20 > `temp-buffer-window-setup-hook' is run with *Help* current. So you > won't have any problems discriminating this special case. How so? (Not clear to me.) `help-window-select' should be for *Help* functions only, not for all uses of `with-output-to-temp-buffer'. But I'm probably not understanding your point. > > 2. Users of `w32*' should not need to do that explicitly > > themselves. Perhaps Emacs can do the equivalent, itself (but > > limited to *Help*, not affecting all temp buffer display). >=20 > I cannot possibly use a feature like `w32-grab-focus-on-raise' whose > semantics I neither understand nor can reenact in my environment in > the frame/window code of Emacs. Do you mean use for testing (this bug)? Or do you mean use in general, for your personal use of Emacs? `w32*' is an Emacs option. It is not something non-Emacs (e.g., from MS Windows), and it is not something that I dreamed up. It, like `help-window-select', should work (for Emacs). No? > But we could change `help-window-setup' as follows: Great. That too (like setting `w32-grab-focus-on-raise' to t in `temp-buffer-window-setup-hook' and setting it to nil in `temp-buffer-window-show-hook') seems to fix the problem, for both the test case and AFAICT in my setup. Would you please make this change to `help-window-setup'? If so, I think we can close the bug. Thanks for your help. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 16 06:37:11 2014 Received: (at 19012) by debbugs.gnu.org; 16 Nov 2014 11:37:11 +0000 Received: from localhost ([127.0.0.1]:34351 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xpy8k-0005ZI-TY for submit@debbugs.gnu.org; Sun, 16 Nov 2014 06:37:11 -0500 Received: from mout.gmx.net ([212.227.15.19]:53598) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xpy8h-0005Yt-EA for 19012@debbugs.gnu.org; Sun, 16 Nov 2014 06:37:09 -0500 Received: from [178.190.163.170] ([178.190.163.170]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Md3ZK-1XYzU41RWU-00IGyz; Sun, 16 Nov 2014 12:37:02 +0100 Message-ID: <54688C53.6060204@gmx.at> Date: Sun, 16 Nov 2014 12:36:51 +0100 From: martin rudalics MIME-Version: 1.0 To: Drew Adams , 19012@debbugs.gnu.org Subject: Re: bug#19012: 25.0.50; `help-window-select' References: <5462561B.2030306@gmx.at> <561951d1-fee4-44ea-bc22-d354b007601d@default> <54646172.7020801@gmx.at> <5464DC39.4020703@gmx.at> <5464FCD5.6070201@gmx.at> <66cb622a-236c-4e8d-a7ba-cb1de310bb05@default> <5465E967.1050304@gmx.at> <41926108-7556-4b72-ae2c-60933b4ff187@default> <5466300D.2030708@gmx.at> <75786231-f3a3-420f-a0d8-4960e09c720e@default> <54663E6F.6010702@gmx.at> <5453eef4-1955-4b79-819a-43786f56a8cc@default> <5466457F.8000400@gmx.at> <54664AF4.9000606@gmx.at> <97868572-923b-4f0a-bd16-b4d475ddb002@default> <5466532C.2040003@gmx.at> <2b53c981-eaef-47f3-850a-6367b4cd5dc1@default> <546737E1.6010406@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:eabw1aezFOfZ4NcOjDE3emGMT6vW2k9oesmuKzeETWKQJxeluVt KdPsFAEDngkawwL67+99ckGAoiq/+Pec3WYlrDH95fDczu9EKBCp6uaVRH4gDAH4iLhAXjV /lakwhU2SVfJcgW2l81hdCHhG7VIACIBf8Q79azPT4NnxPVgZumPXUqNkpzC/PFUeybe9s1 NHe2jNDl8tcwvfUdRRs4w== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) >> `temp-buffer-window-setup-hook' is run with *Help* current. So you >> won't have any problems discriminating this special case. > > How so? (Not clear to me.) You can test if the current buffer shows *Help* and change `w32-grab-focus-on-raise' only in that case. >> I cannot possibly use a feature like `w32-grab-focus-on-raise' whose >> semantics I neither understand nor can reenact in my environment in >> the frame/window code of Emacs. > > Do you mean use for testing (this bug)? I think we have established that "this bug" is not a bug. So please refrain from calling it a bug. > Or do you mean use > in general, for your personal use of Emacs? I don't understand what you mean here. > `w32*' is an Emacs option. It is not something non-Emacs (e.g., > from MS Windows), and it is not something that I dreamed up. > It, like `help-window-select', should work (for Emacs). No? `w32-grab-focus-on-raise' is a variable, not an option. IIUC it is a workaround that might work in some cases. Apparently, it can fail in other cases. > Would you please make this change to `help-window-setup'? It would require further tuning. In its current form it would focus a frame that already has focus which is a bad idea. martin From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 16 11:20:09 2014 Received: (at 19012) by debbugs.gnu.org; 16 Nov 2014 16:20:09 +0000 Received: from localhost ([127.0.0.1]:35483 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xq2Ya-00033n-Ez for submit@debbugs.gnu.org; Sun, 16 Nov 2014 11:20:08 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:16549) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xq2YX-00033d-K9 for 19012@debbugs.gnu.org; Sun, 16 Nov 2014 11:20:06 -0500 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sAGGK2oo006846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 16 Nov 2014 16:20:03 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id sAGGK1t2005461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 16 Nov 2014 16:20:02 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAGGK1FR003341; Sun, 16 Nov 2014 16:20:01 GMT MIME-Version: 1.0 Message-ID: Date: Sun, 16 Nov 2014 08:20:02 -0800 (PST) From: Drew Adams To: martin rudalics , 19012@debbugs.gnu.org Subject: RE: bug#19012: 25.0.50; `help-window-select' References: <5462561B.2030306@gmx.at> <561951d1-fee4-44ea-bc22-d354b007601d@default> <54646172.7020801@gmx.at> <5464DC39.4020703@gmx.at> <5464FCD5.6070201@gmx.at> <66cb622a-236c-4e8d-a7ba-cb1de310bb05@default> <5465E967.1050304@gmx.at> <41926108-7556-4b72-ae2c-60933b4ff187@default> <5466300D.2030708@gmx.at> <75786231-f3a3-420f-a0d8-4960e09c720e@default> <54663E6F.6010702@gmx.at> <5453eef4-1955-4b79-819a-43786f56a8cc@default> <5466457F.8000400@gmx.at> <54664AF4.9000606@gmx.at> <97868572-923b-4f0a-bd16-b4d475ddb002@default> <5466532C.2040003@gmx.at> <2b53c981-eaef-47f3-850a-6367b4cd5dc1@default> <546737E1.6010406@gmx.at> <54688C53.6060204@gmx.at> In-Reply-To: <54688C53.6060204@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > >> `temp-buffer-window-setup-hook' is run with *Help* current. So > >> you won't have any problems discriminating this special case. > > > > How so? (Not clear to me.) >=20 > You can test if the current buffer shows *Help* and change > `w32-grab-focus-on-raise' only in that case. Users should not be fiddling with hooks to work around this bug. Especially hooks intended for more general features (temp buffers in general). > >> I cannot possibly use a feature like `w32-grab-focus-on-raise' > >> whose semantics I neither understand nor can reenact in my > >> environment in the frame/window code of Emacs. > > > > Do you mean use for testing (this bug)? >=20 > I think we have established that "this bug" is not a bug. So please > refrain from calling it a bug. We have not established any such thing. It is a reproducible bug. You even said that if the help window is not selected at the end of `w-h-w' that is a bug. And you found a way to ensure that it is selected - why not just fix that? Anyway, you did not respond to the question. You say that you cannot reenact the symptoms of the recipe in your environment (at least I think that's what you were saying). Why is that? The recipe is 100% reproducible in my environment (Win 7 64-bit). > > Or do you mean use in general, for your personal use of Emacs? >=20 > I don't understand what you mean here. I asked for clarification of what you meant by saying that you "cannot possibly use a feature like `w32-*'". Did you mean use it for your personal use? Did you mean that you cannot test the recipe using it? What did you mean? You answer that question by asking me what I mean by asking what you mean... > > `w32*' is an Emacs option. It is not something non-Emacs (e.g., > > from MS Windows), and it is not something that I dreamed up. > > It, like `help-window-select', should work (for Emacs). No? >=20 > `w32-grab-focus-on-raise' is a variable, not an option. OK, yes; my bad. But is the answer to the question to just be pedantic (yes, I was wrong in thinking it was an option)? My point was that it is an *Emacs* variable. For *user configuration*. It is for users - it is not used in the Lisp source code. And GNU Emacs came up with it, not Microsoft. It should work - for Emacs. > IIUC it is a workaround that might work in some cases. What basis do you have for supposing that it is intended only as a workaround? It is specifically mentioned in the Emacs manual (node `Windows Misc'), and it has been documented there since Emacs 22 (maybe even 21; dunno - it's not in the Emacs 20 manual, but the variable is in Emacs 20). That's the Emacs *user* manual, not the Elisp manual. We point this variable out to *end users*, on purpose. This is not some internal, implementation thing. It is too facile to just declare something that you might not like or might not completely understand is only a "workaround that might work in some cases" and not something that should work generally. > Apparently, it can fail in other cases. You meant this case, this bug, or something else by "other cases"? Attributing this bug to a single variable involved in the recipe is a bit rich. Especially since you found a simple fix for `help-window-setup' that takes care of the bug. > But we could change `help-window-setup' as follows: > > > Would you please make this change to `help-window-setup'? >=20 > It would require further tuning. In its current form it would > focus a frame that already has focus which is a bad idea. What further tuning? Just not focusing a frame that is already focused? And why is focusing a focused frame a bad idea? (Seems like that operation should be idempotent.) You are the expert in this area, not I. I'm not presuming anything. But your response seems enigmatic, if not evasive. Could you *please* fix `help-window-setup' the way you proposed ("we could change `help-window-setup' as follows..."), adding whatever "further tuning" might be necessary? Thank you. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 16 12:36:21 2014 Received: (at 19012) by debbugs.gnu.org; 16 Nov 2014 17:36:21 +0000 Received: from localhost ([127.0.0.1]:35521 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xq3kK-0004yx-B6 for submit@debbugs.gnu.org; Sun, 16 Nov 2014 12:36:20 -0500 Received: from mout.gmx.net ([212.227.17.21]:63948) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xq3kH-0004yo-TO for 19012@debbugs.gnu.org; Sun, 16 Nov 2014 12:36:19 -0500 Received: from [93.82.78.189] ([93.82.78.189]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MHLNn-1XmTFs0JON-00E7wE; Sun, 16 Nov 2014 18:36:16 +0100 Message-ID: <5468E08D.4050508@gmx.at> Date: Sun, 16 Nov 2014 18:36:13 +0100 From: martin rudalics MIME-Version: 1.0 To: Drew Adams , 19012@debbugs.gnu.org Subject: Re: bug#19012: 25.0.50; `help-window-select' References: <561951d1-fee4-44ea-bc22-d354b007601d@default> <54646172.7020801@gmx.at> <5464DC39.4020703@gmx.at> <5464FCD5.6070201@gmx.at> <66cb622a-236c-4e8d-a7ba-cb1de310bb05@default> <5465E967.1050304@gmx.at> <41926108-7556-4b72-ae2c-60933b4ff187@default> <5466300D.2030708@gmx.at> <75786231-f3a3-420f-a0d8-4960e09c720e@default> <54663E6F.6010702@gmx.at> <5453eef4-1955-4b79-819a-43786f56a8cc@default> <5466457F.8000400@gmx.at> <54664AF4.9000606@gmx.at> <97868572-923b-4f0a-bd16-b4d475ddb002@default> <5466532C.2040003@gmx.at> <2b53c981-eaef-47f3-850a-6367b4cd5dc1@default> <546737E1.6010406@gmx.at> <54688C53.6060204@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:O9pePveNmcIpQKQDf3jaWdnrkvrGexfomRvoFI0cxs+guhADcP5 QumqkEFPZBFqMahUYWCCA4eXHd22515FwSfk1m0fV9H8lxYRN9fsgXhY5io6yugwE9/Yw3t gJvV0RejCXxA+W8hCzgWqwDCfWmYi55m004xHEXzZ8lIkCh+G9jE5oFEpqiLUAWmIouNxmJ FwmmmG4HFQJM/YxW71/rA== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) >> You can test if the current buffer shows *Help* and change >> `w32-grab-focus-on-raise' only in that case. > > Users should not be fiddling with hooks to work around this bug. I asked you twice to not call this a bug. This is the last time I ask you to drop it. >> I think we have established that "this bug" is not a bug. So please >> refrain from calling it a bug. > > We have not established any such thing. It is a reproducible bug. No. You have found out yourself that with your scenario the window is selected after `with-help-window' terminates. You might as well complain that (progn (switch-to-buffer "a") (switch-to-buffer "b")) does not show "a" in the selected window where according to its doc-string it should do that. > You even said that if the help window is not selected at the end of > `w-h-w' that is a bug. Yes. And we know meanwhile that it is selected. > And you found a way to ensure that it is > selected - why not just fix that? The window already gets selected. But you want the window's frame get focus too. The doc-string of `help-window-select' does not promise such a thing. So this is not a fix but the implementation of a new feature. > I asked for clarification of what you meant by saying that you > "cannot possibly use a feature like `w32-*'". Did you mean use > it for your personal use? Did you mean that you cannot test the > recipe using it? What did you mean? You answer that question > by asking me what I mean by asking what you mean... I mean that code in help.el or window.el does not act specially with respect to the value of a variable like `w32-grab-focus-on-raise'. >> IIUC it is a workaround that might work in some cases. > > What basis do you have for supposing that it is intended only > as a workaround? The way this variable affects the execution of `raise-frame'. You can convince me of the contrary if you tell me how it does that. > It is specifically mentioned in the Emacs manual (node `Windows > Misc'), and it has been documented there since Emacs 22 (maybe > even 21; dunno - it's not in the Emacs 20 manual, but the variable > is in Emacs 20). That's the Emacs *user* manual, not the Elisp > manual. We point this variable out to *end users*, on purpose. > This is not some internal, implementation thing. There's nothing wrong with that. But using this variable may have unwanted consequences for the user like the one we're talking about here. > It is too facile to just declare something that you might not > like or might not completely understand is only a "workaround > that might work in some cases" and not something that should > work generally. It does not work in general as you stated yourself. When the frame is created it gets focus and setting that variable doesn't help at all. > You meant this case, this bug, or something else by "other cases"? > Attributing this bug to a single variable involved in the recipe > is a bit rich. Especially since you found a simple fix for > `help-window-setup' that takes care of the bug. I proposed a solution to your problem but implementing it is less simple than I thought initially. >> But we could change `help-window-setup' as follows: >> >> > Would you please make this change to `help-window-setup'? >> >> It would require further tuning. In its current form it would >> focus a frame that already has focus which is a bad idea. > > What further tuning? Just not focusing a frame that is already > focused? And why is focusing a focused frame a bad idea? (Seems > like that operation should be idempotent.) It sends a request to the window manager because Emacs doesn't necessarily check whether the frame already has focus. This might not harm on Windows but it might harm on other platforms. > You are the expert in this area, not I. I'm not presuming > anything. But your response seems enigmatic, if not evasive. > > Could you *please* fix `help-window-setup' the way you proposed > ("we could change `help-window-setup' as follows..."), adding > whatever "further tuning" might be necessary? Thank you. I'll try to implement a feature that will focus the frame if it's different from the previous one. Nothing more. martin From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 16 15:06:56 2014 Received: (at 19012) by debbugs.gnu.org; 16 Nov 2014 20:06:56 +0000 Received: from localhost ([127.0.0.1]:35611 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xq662-0003EA-W0 for submit@debbugs.gnu.org; Sun, 16 Nov 2014 15:06:55 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:48775) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xq660-0003Dy-D0 for 19012@debbugs.gnu.org; Sun, 16 Nov 2014 15:06:53 -0500 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sAGK6pHV020568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 16 Nov 2014 20:06:51 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id sAGK6o1q022989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 16 Nov 2014 20:06:50 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAGK6ngl006104; Sun, 16 Nov 2014 20:06:50 GMT MIME-Version: 1.0 Message-ID: <4ea1b6ca-cab4-4d61-97a5-5e17933c9f89@default> Date: Sun, 16 Nov 2014 12:06:50 -0800 (PST) From: Drew Adams To: martin rudalics , 19012@debbugs.gnu.org Subject: RE: bug#19012: 25.0.50; `help-window-select' References: <561951d1-fee4-44ea-bc22-d354b007601d@default> <54646172.7020801@gmx.at> <5464DC39.4020703@gmx.at> <5464FCD5.6070201@gmx.at> <66cb622a-236c-4e8d-a7ba-cb1de310bb05@default> <5465E967.1050304@gmx.at> <41926108-7556-4b72-ae2c-60933b4ff187@default> <5466300D.2030708@gmx.at> <75786231-f3a3-420f-a0d8-4960e09c720e@default> <54663E6F.6010702@gmx.at> <5453eef4-1955-4b79-819a-43786f56a8cc@default> <5466457F.8000400@gmx.at> <54664AF4.9000606@gmx.at> <97868572-923b-4f0a-bd16-b4d475ddb002@default> <5466532C.2040003@gmx.at> <2b53c981-eaef-47f3-850a-6367b4cd5dc1@default> <546737E1.6010406@gmx.at> <54688C53.6060204@gmx.at> <5468E08D.4050508@gmx.at> In-Reply-To: <5468E08D.4050508@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > You have found out yourself that with your scenario the window > is selected after `with-help-window' terminates. >=20 > You might as well complain that > (progn > (switch-to-buffer "a") > (switch-to-buffer "b")) >=20 > does not show "a" in the selected window where according > to its doc-string it should do that. No relation. I am perhaps not using "window selected" correctly. But as a user, how does it help that a window is "selected" if I cannot type into it? Of what use is such selection? You will no doubt say that it means that Lisp can do things in that window, even if I cannot as a user. But my point of view is as a user. So you are free to call this bug report an enhancement request, if you like. And you can consider that it casts no aspersions on `with-help-window' or `help-window-select', but rather it asks that they together give the (user) input focus to the help window (instead of only "selecting" it for Lisp). > > You even said that if the help window is not selected > > at the end of `w-h-w' that is a bug. >=20 > Yes. And we know meanwhile that it is selected. It seems we are now nitpicking over the terms. OK, it is selected, for Lisp. It does not have the input focus, for a user. The latter is what is important to me. And honestly, isn't that the behavior you intended in the first place? Did you even consider the other-frame case? (I'm not saying you should have; I'm just asking.) For the same-frame case, the behavior is the same for selection and input focus. So for that case (which I imagine you had in mind, and tested) there is no bug fix or enhancement needed. The behavior is just what a user wants and expects. For the other-frame case the behavior is still broken (inadequate), from my point of view. I'm really only asking that that case be fixed so that the user experience is parallel to the same-frame case: the *Help* window gets the focus, so that if a user hits, say, `q' it disappears (as opposed to `q' being inserted in the original buffer). > > And you found a way to ensure that it is > > selected - why not just fix that? >=20 > The window already gets selected. But you want the > window's frame get focus too. Yes. You understand correctly. > The doc-string of `help-window-select' does not > promise such a thing. You wrote that doc string, I imagine. I also imagine that perhaps you did not consider the other-frame case. In any case, I am requesting exactly that same behavior, so that a user for the separate-frame use case has the same experience as a user for the same-frame case: s?he can interact directly and immediately with the *Help* window using the keyboard. If s?he hits `q' then it should be the *Help* window and buffer that receive the `q'. > So this is not a fix but the implementation of a new > feature. If you like. Or a missing part of the feature you added. The feature you added does not handle the other-frame case. And it should. That's what this bug report or enhancement request is for. It's not about establishing in a court of law whether the doc string's promise of the window being selected is in fact fulfilled. Nobody is suing anyone here. And I'm not criticizing the work you did in adding this feature. I'm just saying that it will help people if it is extended to the other-frame case as well. It's about helping users and doing the right thing, not justifying the status quo. > > It is specifically mentioned in the Emacs manual (node `Windows > > Misc'), and it has been documented there since Emacs 22 (maybe > > even 21; dunno - it's not in the Emacs 20 manual, but the > > variable is in Emacs 20). That's the Emacs *user* manual, > > not the Elisp manual. We point this variable out to *end > > users*, on purpose. This is not some internal, implementation=20 > > thing. >=20 > There's nothing wrong with that. But using this variable may have > unwanted consequences for the user like the one we're talking about > here. Anything could have unwanted consequences. Clearly, the intention of those who provided `w32*' was to allow users to choose to have `raise-frame' grab the focus. Nothing more or less than that. > > It is too facile to just declare something that you might not > > like or might not completely understand is only a "workaround > > that might work in some cases" and not something that should > > work generally. >=20 > It does not work in general as you stated yourself. > When the frame is created it gets focus and setting that > variable doesn't help at all. You are acting like a lawyer. "Generally" does not necessarily mean in every single case. If there were a simple fix for the MS Windows problem of it focusing new frames then Emacs would have implemented that. The inability to fix that problem does not provide an excuse not to fix this problem. Fix this problem and you will have advanced the ability to use this feature "in general". > > You meant this case, this bug, or something else by > > "other cases"? Attributing this bug to a single variable > > involved in the recipe is a bit rich. Especially since > > you found a simple fix for `help-window-setup' that takes > > care of the bug. >=20 > I proposed a solution to your problem but implementing it > is less simple than I thought initially. How so? Can you discuss those problems? Is adding that sexp to `help-window-setup' worse than if the equivalent behavior were done in `with-output-to-temp-buffer'? IOW, if a user fiddles with the temp-buffer hooks, is that workaround any less problematic? If so, maybe you can fix the problem by doing the equivalent of a user fiddling with hooks that way. IOW, maybe put that code in the code that runs the hooks, instead of telling users put it in the hooks. I'm speculating, because you have said nothing about what the problems are that make things "less simple than [you] thought initially". > >> But we could change `help-window-setup' as follows: > >> > >> > Would you please make this change to `help-window-setup'? > >> > >> It would require further tuning. In its current form it would > >> focus a frame that already has focus which is a bad idea. > > > > What further tuning? Just not focusing a frame that is already > > focused? And why is focusing a focused frame a bad idea? > > (Seems like that operation should be idempotent.) >=20 > It sends a request to the window manager because Emacs doesn't > necessarily check whether the frame already has focus. This > might not harm on Windows but it might harm on other platforms. Then either (1) do it and wait to see if problems are reported for other platforms or (2) do it just for Windows (that's simple enough to do). IOW why make the ideal into the enemy of the good? And why assume that there will be problems on other platforms? > > You are the expert in this area, not I. I'm not presuming > > anything. But your response seems enigmatic, if not evasive. > > > > Could you *please* fix `help-window-setup' the way you proposed > > ("we could change `help-window-setup' as follows..."), adding > > whatever "further tuning" might be necessary? Thank you. >=20 > I'll try to implement a feature that will focus the frame if > it's different from the previous one. Nothing more. I appreciate your efforts on this (whether you think so or not). I am certain that if you try to improve the situation for this use case you can do so, and without spoiling other behavior, even if the fix might not be 100% perfect. Please give it a try. Thx. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 17 04:29:24 2014 Received: (at 19012) by debbugs.gnu.org; 17 Nov 2014 09:29:24 +0000 Received: from localhost ([127.0.0.1]:35750 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XqIce-0002bt-BM for submit@debbugs.gnu.org; Mon, 17 Nov 2014 04:29:24 -0500 Received: from mout.gmx.net ([212.227.15.15]:62639) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XqIcb-0002bd-RA for 19012@debbugs.gnu.org; Mon, 17 Nov 2014 04:29:23 -0500 Received: from [178.191.143.215] ([178.191.143.215]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LtIZH-1Xx3eo2Amp-012rLo; Mon, 17 Nov 2014 10:29:17 +0100 Message-ID: <5469BFEB.6060506@gmx.at> Date: Mon, 17 Nov 2014 10:29:15 +0100 From: martin rudalics MIME-Version: 1.0 To: Drew Adams , 19012@debbugs.gnu.org Subject: Re: bug#19012: 25.0.50; `help-window-select' References: <561951d1-fee4-44ea-bc22-d354b007601d@default> <54646172.7020801@gmx.at> <5464DC39.4020703@gmx.at> <5464FCD5.6070201@gmx.at> <66cb622a-236c-4e8d-a7ba-cb1de310bb05@default> <5465E967.1050304@gmx.at> <41926108-7556-4b72-ae2c-60933b4ff187@default> <5466300D.2030708@gmx.at> <75786231-f3a3-420f-a0d8-4960e09c720e@default> <54663E6F.6010702@gmx.at> <5453eef4-1955-4b79-819a-43786f56a8cc@default> <5466457F.8000400@gmx.at> <54664AF4.9000606@gmx.at> <97868572-923b-4f0a-bd16-b4d475ddb002@default> <5466532C.2040003@gmx.at> <2b53c981-eaef-47f3-850a-6367b4cd5dc1@default> <546737E1.6010406@gmx.at> <54688C53.6060204@gmx.at> <5468E08D.4050508@gmx.at> <4ea1b6ca-cab4-4d61-97a5-5e17933c9f89@default> In-Reply-To: <4ea1b6ca-cab4-4d61-97a5-5e17933c9f89@default> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:7rwHefj9O/Zcc4je0lq06G+G0zN+jGLWTWKkSxWmZ90GTPtIDm6 N4Gf1jfhWbF/py1XE8szKx/V5qizquNsgIlaCGLZj2erHL1AbBmcrLdqbMVIViS9H1e92yC rMARoYdc9HYyqIbcvM4Us2gS7Am/DVgBL1aJLbF91/O/6qh9mzwsi0511e5i3TXwnIGgF/1 CDQmjnxLfSiRgi1RsWz2A== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > How so? Can you discuss those problems? Is adding that sexp > to `help-window-setup' worse than if the equivalent behavior > were done in `with-output-to-temp-buffer'? IOW, if a user > fiddles with the temp-buffer hooks, is that workaround any > less problematic? Not for the user. But users fiddling with these hooks affect their own systems only. > If so, maybe you can fix the problem by doing the equivalent > of a user fiddling with hooks that way. IOW, maybe put that > code in the code that runs the hooks, instead of telling > users put it in the hooks. Again I would affect users who don't work with multiple frames. > I'm speculating, because you have said nothing about what > the problems are that make things "less simple than [you] > thought initially". I initially thought (like you did too) that Emacs would not send a request to focus a frame that already has focus. After looking into this I noticed that it does send a request unconditionally. >> It sends a request to the window manager because Emacs doesn't >> necessarily check whether the frame already has focus. This >> might not harm on Windows but it might harm on other platforms. > > Then either (1) do it and wait to see if problems are reported > for other platforms or (2) do it just for Windows (that's simple > enough to do). It's not nice to do that even for Windows only. > IOW why make the ideal into the enemy of the good? And why > assume that there will be problems on other platforms? Because I try to be as minimally invasive as possible. > I appreciate your efforts on this (whether you think so or > not). I am certain that if you try to improve the situation > for this use case you can do so, and without spoiling other > behavior, even if the fix might not be 100% perfect. Please > give it a try. I'll do that. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 17 09:29:49 2014 Received: (at 19012) by debbugs.gnu.org; 17 Nov 2014 14:29:50 +0000 Received: from localhost ([127.0.0.1]:35883 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XqNJN-0003By-5Y for submit@debbugs.gnu.org; Mon, 17 Nov 2014 09:29:49 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:47533) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XqNJJ-0003Bi-Cy for 19012@debbugs.gnu.org; Mon, 17 Nov 2014 09:29:45 -0500 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sAHETiTi015194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Nov 2014 14:29:44 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAHETh01015821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2014 14:29:43 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id sAHETgLE015150; Mon, 17 Nov 2014 14:29:42 GMT MIME-Version: 1.0 Message-ID: <7a8b49a4-0808-4b7c-9848-26e0b57a2e0e@default> Date: Mon, 17 Nov 2014 06:29:42 -0800 (PST) From: Drew Adams To: martin rudalics , 19012@debbugs.gnu.org Subject: RE: bug#19012: 25.0.50; `help-window-select' References: <561951d1-fee4-44ea-bc22-d354b007601d@default> <54646172.7020801@gmx.at> <5464DC39.4020703@gmx.at> <5464FCD5.6070201@gmx.at> <66cb622a-236c-4e8d-a7ba-cb1de310bb05@default> <5465E967.1050304@gmx.at> <41926108-7556-4b72-ae2c-60933b4ff187@default> <5466300D.2030708@gmx.at> <75786231-f3a3-420f-a0d8-4960e09c720e@default> <54663E6F.6010702@gmx.at> <5453eef4-1955-4b79-819a-43786f56a8cc@default> <5466457F.8000400@gmx.at> <54664AF4.9000606@gmx.at> <97868572-923b-4f0a-bd16-b4d475ddb002@default> <5466532C.2040003@gmx.at> <2b53c981-eaef-47f3-850a-6367b4cd5dc1@default> <546737E1.6010406@gmx.at> <54688C53.6060204@gmx.at> <5468E08D.4050508@gmx.at> <4ea1b6ca-cab4-4d61-97a5-5e17933c9f89@default> <5469BFEB.6060506@gmx.at> In-Reply-To: <5469BFEB.6060506@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 19012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > I try to be as minimally invasive as possible. That's good. It's good to be careful, as you are. > > I appreciate your efforts on this (whether you think so or > > not). I am certain that if you try to improve the situation > > for this use case you can do so, and without spoiling other > > behavior, even if the fix might not be 100% perfect. Please > > give it a try. >=20 > I'll do that. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 25 14:30:38 2014 Received: (at 19012-done) by debbugs.gnu.org; 25 Dec 2014 19:30:38 +0000 Received: from localhost ([127.0.0.1]:57509 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y4E7K-0006mS-Ek for submit@debbugs.gnu.org; Thu, 25 Dec 2014 14:30:38 -0500 Received: from mout.gmx.net ([212.227.15.18]:58885) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y4E7H-0006mK-Qb for 19012-done@debbugs.gnu.org; Thu, 25 Dec 2014 14:30:36 -0500 Received: from [188.22.32.76] ([188.22.32.76]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lta9E-1XuMB11tfY-010r6B; Thu, 25 Dec 2014 20:30:31 +0100 Message-ID: <549C65CE.6000308@gmx.at> Date: Thu, 25 Dec 2014 20:30:22 +0100 From: martin rudalics MIME-Version: 1.0 To: Drew Adams , 19012-done@debbugs.gnu.org Subject: Re: bug#19012: 25.0.50; `help-window-select' References: <5464DC39.4020703@gmx.at> <5464FCD5.6070201@gmx.at> <66cb622a-236c-4e8d-a7ba-cb1de310bb05@default> <5465E967.1050304@gmx.at> <41926108-7556-4b72-ae2c-60933b4ff187@default> <5466300D.2030708@gmx.at> <75786231-f3a3-420f-a0d8-4960e09c720e@default> <54663E6F.6010702@gmx.at> <5453eef4-1955-4b79-819a-43786f56a8cc@default> <5466457F.8000400@gmx.at> <54664AF4.9000606@gmx.at> <97868572-923b-4f0a-bd16-b4d475ddb002@default> <5466532C.2040003@gmx.at> <2b53c981-eaef-47f3-850a-6367b4cd5dc1@default> <546737E1.6010406@gmx.at> <54688C53.6060204@gmx.at> <5468E08D.4050508@gmx.at> <4ea1b6ca-cab4-4d61-97a5-5e17933c9f89@default> <5469BFEB.6060506@gmx.at> <7a8b49a4-0808-4b7c-9848-26e0b57a2e0e@default> In-Reply-To: <7a8b49a4-0808-4b7c-9848-26e0b57a2e0e@default> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:bmfzb0u+p/9KcBI6hYehhW2AWHJsIo88aBq80oAAePsnTC8E1AW OmMQzy897o9XEbcU0/IMTj0prbyB4JmURopttO7woUy6wjV0ekRgkoQrC0Vjxa4EelA9Ljb 2vJXOWm/tir6+mwTgnDJBlKoPLQqi9A7AFQ3TxmCcNqXoy6TQwlNV9nVUwUbEb2pwXjCVno UsHjnbetNIRbSM1f6CS0g== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19012-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) >> > I appreciate your efforts on this (whether you think so or >> > not). I am certain that if you try to improve the situation >> > for this use case you can do so, and without spoiling other >> > behavior, even if the fix might not be 100% perfect. Please >> > give it a try. >> >> I'll do that. Done on Emacs 25.0.50.1. Bug closed. Thanks, martin From unknown Tue Jun 24 15:42:55 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 23 Jan 2015 12:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator