From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: view mode: `q' does not delete frame Date: Thu, 1 Dec 2005 17:57:16 -0800 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1133488701 17555 80.91.229.2 (2 Dec 2005 01:58:21 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 2 Dec 2005 01:58:21 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 02 02:58:19 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Ei0BT-0007VM-3l for ged-emacs-devel@m.gmane.org; Fri, 02 Dec 2005 02:58:01 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ei0BR-0003s9-Un for ged-emacs-devel@m.gmane.org; Thu, 01 Dec 2005 20:57:58 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ei0B8-0003qU-4K for emacs-devel@gnu.org; Thu, 01 Dec 2005 20:57:38 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ei0B2-0003l3-TC for emacs-devel@gnu.org; Thu, 01 Dec 2005 20:57:37 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ei0B2-0003kd-Lw for emacs-devel@gnu.org; Thu, 01 Dec 2005 20:57:32 -0500 Original-Received: from [148.87.122.30] (helo=rgminet01.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1Ei0B1-0002Cu-S3 for emacs-devel@gnu.org; Thu, 01 Dec 2005 20:57:32 -0500 Original-Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id jB21vN7c010863 for ; Thu, 1 Dec 2005 18:57:24 -0700 Original-Received: from rgmsgw300.us.oracle.com (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jB21vNY6007948 for ; Thu, 1 Dec 2005 18:57:23 -0700 Original-Received: from dradamslap (dhcp-amer-rmdc-csvpn-gw5-141-144-104-13.vpn.oracle.com [141.144.104.13]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jB21vMBN007942 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 1 Dec 2005 18:57:23 -0700 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:46866 Archived-At: I looked into this and found a small mess. First, view-mode is only supposed to delete the frame if you set view-remove-frame-by-deleting to a non-nil value; otherwise it iconifies the frame. Did you set that variable? if not, View Mode is not supposed to do what you want. Yes, that's what I ended up doing. I found that option after I filed the report in September, though. I guess the apropos-zippy behavior is independent of the previously reported problem. But don't rush to set it just yet, `cause that's just the tip of an iceberg. The apropos and help commands don't invoke the full view-mode as it was supposed to be, via view-mode-enter; instead, they call view-mode directly, and arrange for what happens when you type `q' in the function `print-help-return-message'. That function sets the variable help-return-method, but it doesn't support pop-up-frames, only pop-up-windows, special-display-buffer-names and special-display-regexps. If I use one of the special-display-* variables to include *Help* and *Apropos* buffers in the respective lists, the frames that show those buffers are deleted when I press `q'. I'm guessing that you didn't set special-display-* variables to include any of the buffers mentioned in this thread. Yes, I have special-display-regexps's = ("[ ]?[*][^*]+[*]"). But even setting special-display-* doesn't work for `apropos-zippy', since it fails to call `print-help-return-message', like the other help commands do, and thus help return method is left at its default. This is a bug in yow.el, I think. I guess that's all this last gripe concerns, then: `apropos-zippy'. I was thinking this was related to the previous report and, frankly, I had forgotten that I had found and set view-remove-frame-by-deleting. I would prefer, of course, that if pop-up-frames = non-nil, the behavior of view-remove-frame-by-deleting would follow automatically (by default). For example, instead of having the default value be nil, have it be (not pop-up-frames). So, unless someone finds where I'm wrong in my conclusions, I think we should modify `print-help-return-message' to support pop-up-frames, and add a call to `print-help-return-message' in `apropos-zippy'. Any objections or further insights, anyone? Finally, I'd like to respond to your gripes (expressed in some quite strong language, too strong if you ask me) in your original message back in September about the names of the View-* functions that exit the view mode in various ways. I do agree that some of the names are not descriptive enough, so I suggest the following changes in those names: View-quit -> View-quit (no change) View-quit-all -> View-quit-restore-all-windows View-exit -> View-exit-view-mode View-exit-and-edit -> View-edit View-leave -> View-quit-keep-current-buffer View-kill-and-leave -> View-quit-kill-current-buffer WDYT? Sorry about the sarcasm (one person's funny is another person's annoying). I was frustrated with view-mode, but I didn't mean to harm any humans while venting against it. My take on the names: The functions are all ways of quitting view-mode, so they should all start with View-quit (or View-exit or ...) - no mixing of synonyms (exit etc.). None of them should be called just View-quit, as none of them seems to be the "main" (default) way of quitting, and even if one were, people would still wonder what it does specifically. Judging by the doc strings, these names come to mind: - View-quit-keep-buffer - View-quit-edit-buffer - View-quit-kill-buffer - View-quit-restore-all-buffers - View-quit-restore-other-buffer (but it's not clear which buffer is restored). My main question about the names cannot be addressed for this release: Is it really necessary to have so many ways to quit? Could this proliferation be a sign that the design is not as it should be? Why does quitting a mode need to be so concerned about which context to restore? Perhaps the restoration context should be passed when the mode is entered? Or perhaps the caller should control it some other way. And so on. It seems odd to me that a function is so concerned with how it was called. Thanks, Drew