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 11:21:28 -0800 (PST) Message-ID: <66cb622a-236c-4e8d-a7ba-cb1de310bb05@default> References: <5460F5B3.6040402@gmx.at> <8e78202d-5ac0-4df5-8195-9849dd7509b7@default> <5461C901.6060707@gmx.at> <3f833473-f246-4d57-95cd-2ac654d326c9@default> <5462561B.2030306@gmx.at> <561951d1-fee4-44ea-bc22-d354b007601d@default> <54646172.7020801@gmx.at> <5464DC39.4020703@gmx.at> <5464FCD5.6070201@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 1415906551 3347 80.91.229.3 (13 Nov 2014 19:22:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Nov 2014 19:22:31 +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 20:22: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 1XozyK-00037U-42 for geb-bug-gnu-emacs@m.gmane.org; Thu, 13 Nov 2014 20:22:24 +0100 Original-Received: from localhost ([::1]:33569 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XozyJ-0006Cd-Mf for geb-bug-gnu-emacs@m.gmane.org; Thu, 13 Nov 2014 14:22:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41508) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xozy7-00060F-5i for bug-gnu-emacs@gnu.org; Thu, 13 Nov 2014 14:22:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xozxy-0000ai-Er for bug-gnu-emacs@gnu.org; Thu, 13 Nov 2014 14:22:11 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34274) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xozxy-0000ae-Be for bug-gnu-emacs@gnu.org; Thu, 13 Nov 2014 14:22:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Xozxy-0008Rk-1j for bug-gnu-emacs@gnu.org; Thu, 13 Nov 2014 14:22: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 19:22:01 +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.141590649732430 (code B ref 19012); Thu, 13 Nov 2014 19:22:01 +0000 Original-Received: (at 19012) by debbugs.gnu.org; 13 Nov 2014 19:21:37 +0000 Original-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 Original-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 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 sADJLU86015611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Nov 2014 19:21:32 GMT Original-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 Original-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 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)] 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:95946 > > 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.