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: Sun, 16 Nov 2014 08:20:02 -0800 (PST) Message-ID: 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> 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 1416154894 11868 80.91.229.3 (16 Nov 2014 16:21:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Nov 2014 16:21:34 +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 Sun Nov 16 17:21: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 1Xq2Zo-0003Z0-FD for geb-bug-gnu-emacs@m.gmane.org; Sun, 16 Nov 2014 17:21:24 +0100 Original-Received: from localhost ([::1]:44288 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xq2Zn-00037M-Rg for geb-bug-gnu-emacs@m.gmane.org; Sun, 16 Nov 2014 11:21:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50494) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xq2Zb-000377-Km for bug-gnu-emacs@gnu.org; Sun, 16 Nov 2014 11:21:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xq2ZS-00038x-SC for bug-gnu-emacs@gnu.org; Sun, 16 Nov 2014 11:21:11 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38270) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xq2ZS-00038p-ON for bug-gnu-emacs@gnu.org; Sun, 16 Nov 2014 11:21:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Xq2ZS-00035F-FQ for bug-gnu-emacs@gnu.org; Sun, 16 Nov 2014 11:21: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: Sun, 16 Nov 2014 16:21: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.141615480911772 (code B ref 19012); Sun, 16 Nov 2014 16:21:02 +0000 Original-Received: (at 19012) by debbugs.gnu.org; 16 Nov 2014 16:20:09 +0000 Original-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 Original-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 Original-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 Original-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 Original-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 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)] X-Source-IP: ucsinet22.oracle.com [156.151.31.94] 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:96125 > >> `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.