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 07:23:54 -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> 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 1415892273 30824 80.91.229.3 (13 Nov 2014 15:24:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Nov 2014 15:24:33 +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 16:24:26 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 1XowG1-00071D-NX for geb-bug-gnu-emacs@m.gmane.org; Thu, 13 Nov 2014 16:24:25 +0100 Original-Received: from localhost ([::1]:60498 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XowG1-0005ul-AB for geb-bug-gnu-emacs@m.gmane.org; Thu, 13 Nov 2014 10:24:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33224) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XowFp-0005t8-F0 for bug-gnu-emacs@gnu.org; Thu, 13 Nov 2014 10:24:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XowFf-0002QF-L6 for bug-gnu-emacs@gnu.org; Thu, 13 Nov 2014 10:24:13 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34059) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XowFf-0002Pn-IQ for bug-gnu-emacs@gnu.org; Thu, 13 Nov 2014 10:24:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XowFe-0006ga-Pq for bug-gnu-emacs@gnu.org; Thu, 13 Nov 2014 10:24: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 15:24: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.141589224125691 (code B ref 19012); Thu, 13 Nov 2014 15:24:02 +0000 Original-Received: (at 19012) by debbugs.gnu.org; 13 Nov 2014 15:24:01 +0000 Original-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 Original-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 Original-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 Original-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 Original-Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sADFNskT017107; Thu, 13 Nov 2014 15:23:55 GMT 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)] X-Source-IP: ucsinet21.oracle.com [156.151.31.93] 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:95923 > > 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'.