From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#19012: 25.0.50; `help-window-select' Date: Thu, 13 Nov 2014 08:56:53 -0800 (PST) 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> <561951d1-fee4-44ea-bc22-d354b007601d@default> <54646172.7020801@gmx.at> <5464DC39.4020703@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1415897852 4510 80.91.229.3 (13 Nov 2014 16:57:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Nov 2014 16:57:32 +0000 (UTC) To: martin rudalics , 19012@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 13 17:57:24 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xoxhy-0005uZ-PY for geb-bug-gnu-emacs@m.gmane.org; Thu, 13 Nov 2014 17:57:23 +0100 Original-Received: from localhost ([::1]:32800 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xoxhy-0004OF-GQ for geb-bug-gnu-emacs@m.gmane.org; Thu, 13 Nov 2014 11:57:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60345) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xoxhn-0004NK-Gr for bug-gnu-emacs@gnu.org; Thu, 13 Nov 2014 11:57:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xoxhe-0000Bm-Op for bug-gnu-emacs@gnu.org; Thu, 13 Nov 2014 11:57:11 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34133) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xoxhe-0000Bf-LX for bug-gnu-emacs@gnu.org; Thu, 13 Nov 2014 11:57:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Xoxhe-000219-BO for bug-gnu-emacs@gnu.org; Thu, 13 Nov 2014 11:57:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 13 Nov 2014 16:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19012 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19012-submit@debbugs.gnu.org id=B19012.14158978207747 (code B ref 19012); Thu, 13 Nov 2014 16:57:02 +0000 Original-Received: (at 19012) by debbugs.gnu.org; 13 Nov 2014 16:57:00 +0000 Original-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 Original-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 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sADGutkW013622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Nov 2014 16:56:56 GMT Original-Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sADGusx3001485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Nov 2014 16:56:55 GMT Original-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 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)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:95929 > > 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.