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 12:06:50 -0800 (PST) Message-ID: <4ea1b6ca-cab4-4d61-97a5-5e17933c9f89@default> 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> 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 1416168461 28211 80.91.229.3 (16 Nov 2014 20:07:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Nov 2014 20:07:41 +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 21:07:28 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 1Xq66X-0006oh-Bs for geb-bug-gnu-emacs@m.gmane.org; Sun, 16 Nov 2014 21:07:25 +0100 Original-Received: from localhost ([::1]:44973 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xq66W-0005fX-7b for geb-bug-gnu-emacs@m.gmane.org; Sun, 16 Nov 2014 15:07:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55815) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xq66J-0005fS-IX for bug-gnu-emacs@gnu.org; Sun, 16 Nov 2014 15:07:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xq66A-0005vT-Nt for bug-gnu-emacs@gnu.org; Sun, 16 Nov 2014 15:07:11 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38398) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xq66A-0005vP-Jy for bug-gnu-emacs@gnu.org; Sun, 16 Nov 2014 15:07:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Xq66A-0003Ea-78 for bug-gnu-emacs@gnu.org; Sun, 16 Nov 2014 15:07: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 20:07: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.141616841612415 (code B ref 19012); Sun, 16 Nov 2014 20:07:02 +0000 Original-Received: (at 19012) by debbugs.gnu.org; 16 Nov 2014 20:06:56 +0000 Original-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 Original-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 Original-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 Original-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 Original-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 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)] 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:96134 > 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.