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: RE: q doesn't always quit *Help* Date: Fri, 28 Sep 2007 07:26:26 -0700 Message-ID: References: <46FCA0C2.1020405@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1190989628 19492 80.91.229.12 (28 Sep 2007 14:27:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 28 Sep 2007 14:27:08 +0000 (UTC) Cc: Bug-Gnu-Emacs To: "martin rudalics" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Sep 28 16:27:04 2007 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IbGnp-0005ed-7q for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Sep 2007 16:26:49 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IbGnl-0007Zv-Dq for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Sep 2007 10:26:45 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IbGnj-0007YA-78 for bug-gnu-emacs@gnu.org; Fri, 28 Sep 2007 10:26:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IbGni-0007Xg-NQ for bug-gnu-emacs@gnu.org; Fri, 28 Sep 2007 10:26:42 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IbGni-0007Xb-GO for bug-gnu-emacs@gnu.org; Fri, 28 Sep 2007 10:26:42 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IbGni-0007IR-4I for bug-gnu-emacs@gnu.org; Fri, 28 Sep 2007 10:26:42 -0400 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l8SEQcfG013616; Fri, 28 Sep 2007 09:26:38 -0500 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id l8SEQZZE023024; Fri, 28 Sep 2007 08:26:36 -0600 Original-Received: from dhcp-amer-csvpn-gw2-141-144-74-29.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 3253674191190989582; Fri, 28 Sep 2007 07:26:22 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <46FCA0C2.1020405@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Detected-Kernel: Linux 2.4-2.6 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:16642 Archived-At: > >>`quit-window' deletes the frame iff it's a minibuffer-window - which > >>should not hold here - or it's a dedicated window - do you set that? > > > > As I said, it deletes the frame in my code. And yes, *Help* is > > probably also a dedicated window for me - it is a special-display > > frame for me, in any case. > > If you change this manually I can't help you. Any solution I provide > here must rely on the standard settings. Yes, of course. My point was that `quit-window' (or equivalent) is correct and sufficient here - for both me and users without non-nil `pop-up-frames'. That behavior is all that is necessary, IMO. I don't see why anyone would (ever) need more than to quit the window. FWIW, in my case, `quit-window' is sufficient because I have modified `delete-window' to delete the frame also if `one-window-p'. Beyond the current bug, Emacs does not play well with frames. Fixing this bug should not attempt to fix more than this bug, and the behavior of `quit-window' is enough to fix this bug, IMO. To go beyond this bug, `delete-window' should do what I just described - but that is a different deficiency. > `view-mode-exit' has the > following code to cope with stand-alone frames: > > ((not (eq frame (next-frame))) > ;; Not the only frame, so can safely be removed. > (if view-remove-frame-by-deleting > (delete-frame frame) > (setq notlost t) ; Keep the window. > See below. > (iconify-frame frame)))))) I do have `view-remove-frame-by-deleting' = t, yet *Help* was iconified (after your fix). Sorry, I don't have a recipe now. In any case, `q' in *Help* does various things (before your fix - I haven't tested enough with the fix) in various contexts - (1) sometimes it does nothing - no feedback, nada - useless; (2) sometimes it deletes the window (& frame) - correct; (3) sometimes it iconifies the frame - awful. I assume this variety is due to the complexity of the View mode code, but I don't pretend to understand the causes. Besides the fact that #3 is awful and #1 is useless, it is not good that the behavior is variable. > Hence if your view-mode frame is not the only frame it should get > deleted provided you have set `view-remove-frame-by-deleting' to > non-nil. `quit-window' should never delete such frames. Don't worry about `quit-window' not deleting the frame - deleting the window is suffient. With my own code it also deletes the frame, but don't worry about that. Without my code, if other users eventually complain that the frame too should be deleted, then the place to fix that is not in View mode - it is by simply making `delete-window' delete the frame when `one-window-p'. > Did you customize `view-remove-frame-by-deleting'? Yes, it is `t'. > >>But I agree that the behavior you describe is logical and desirable (as > >>long as you never display anything else in that window). > > > > I don't [think] the part in parentheses is needed - so what if you do > > at some time display another buffer in that window? > > If it's a view-mode buffer it should always rely on the _latest_ > information established by `with-help-window'. This information should > be kept when you follow links or xrefs. For any other buffer "q" > hopefully has the effect the respective major mode assigns it. OK, I don't pretend to follow the View-mode logic; I'm sure you're right. In my ignorance, I think the whole approach of View mode for `q' since Emacs 22 is a mistake - trying to keep track of what series of events set up the current context, to determine the smartest way to "quit". To me, it doesn't make much sense for a function to try to keep track, in a complex way, of how (it thinks) it was called and change its behavior in complex ways accordingly. View mode worked fine in Emacs 20 and 21, IMO, and now it is beyond hope. Call me a pessimist. And I do admit to ignorance on this - I'm just relating my experience as a user. I am not claiming I know how to design View mode so that it does TRT in all contexts. It just feels terribly wrong when I look at the code. > >> Hence, I have to invent something here. Did you try this with > >>`help-window-select' customized? > > > > No, I never heard of it. And I don't see it in Emacs 22.1 (or > > in 21 or 20), which is what I use. What is it, and how might > > it help here? > > That's the new option I wrote for help.el. With pop-up frames it > shouldn't make much difference I suppose. Was it in the patch? I didn't notice it. Anyway, thanks for fixing this bug. For the rest, we shall see. If I get a recipe for other problems I'll let you know. My general wish is that someone revamp the View-mode code to simplify it and remove the klunky "cleverness". I think it should not try to have 18 zillion different behaviors, depending on how it thinks it might have been called and what it thinks the user might be intending.