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: delete-windows-on Date: Fri, 2 Oct 2009 09:16:56 -0700 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1254500250 27382 80.91.229.12 (2 Oct 2009 16:17:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 2 Oct 2009 16:17:30 +0000 (UTC) To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 02 18:17:23 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Mtkop-0004xx-L9 for ged-emacs-devel@m.gmane.org; Fri, 02 Oct 2009 18:17:19 +0200 Original-Received: from localhost ([127.0.0.1]:59495 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mtkoo-0004C4-L1 for ged-emacs-devel@m.gmane.org; Fri, 02 Oct 2009 12:17:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mtkoh-00049i-2K for emacs-devel@gnu.org; Fri, 02 Oct 2009 12:17:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mtkoc-000443-M6 for emacs-devel@gnu.org; Fri, 02 Oct 2009 12:17:10 -0400 Original-Received: from [199.232.76.173] (port=38001 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mtkoc-00043z-CU for emacs-devel@gnu.org; Fri, 02 Oct 2009 12:17:06 -0400 Original-Received: from acsinet11.oracle.com ([141.146.126.233]:18099) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mtkob-0001sa-QP for emacs-devel@gnu.org; Fri, 02 Oct 2009 12:17:06 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n92GH7xx026548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 2 Oct 2009 16:17:08 GMT Original-Received: from abhmt007.oracle.com (abhmt007.oracle.com [141.146.116.16]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n92GHgOc003051 for ; Fri, 2 Oct 2009 16:17:42 GMT Original-Received: from dradamslap1 (/24.5.184.158) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Oct 2009 09:16:58 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpDe8LTKnSoynNXRYiy5D8KMHFinQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt007.oracle.com [141.146.116.16] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4AC6277A.01AB:SCFSTAT5015188,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) 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:115847 Archived-At: Some questions and suggestions regarding `delete-windows-on'. 1. Why is this defined in C? Is that needed for performance reasons? If not, why not move it to Lisp? 2. It returns nil if you pass nil as the BUFFER arg. That's OK, in itself. But even though undocumented, some Emacs code has in fact depended on this return value. (Calc, for example - see bug "Minor problem with calc-quit", filed 2006-05-30, though this has apparently been fixed.) Dunno if any code currently depends on it. 3. It raises an error if you pass the name of a non-existent buffer, or if you pass anything that is not a string or a buffer (except nil - see #2). Why? Why doesn't it just do nothing if the BUFFER arg is not an existing buffer or its name? A nil value of BUFFER means there is no such buffer. The same is true of a string that doesn't name an existing buffer. The same is true of a non-string such as the number 42. In one case (#2), we currently do nothing and return nil; in all other cases (#3), we currently raise an error. That's not very consistent. IMO, we should never raise an error when BUFFER doesn't correspond to an existing buffer - we should just do nothing (there are simply no windows to delete). The only purpose of `delete-windows-on' should be to delete windows - it should not also be interpreted as a test for whether BUFFER actually corresponds to a buffer. 4. Either the return value is important and part of the design (interface), or not. If the former, then the return value should be documented (in the special case of a nil BUFFER and in all other cases). If the latter, then we should ensure that none of the existing code depends on the return value. 5. The completion list of `delete-windows-on' is currently all (non-internal) buffers, even buffers that are not displayed anywhere. If you are calling `delete-windows-on' interactively, then you are not interested in deleting the windows of buffers that do not have windows (!). It would be better therefore to have `interactive' propose only displayed buffers. The `interactive' code could either allow as candidate any buffer displayed in any frame, or it could check the FRAME arg and propose only buffers that are compatible (consistent) with FRAME. Either approach would be reasonable, but probably the former is more flexible for users, especially those who use multiple frames a lot. Here is an example of this approach (any buffer displayed anywhere is a candidate): (completing-read "Delete windows on buffer: " (let ((all-bufs (buffer-list)) (cand-bufs ())) (dolist (buf all-bufs) (when (get-buffer-window buf t) (push (list (buffer-name buf)) cand-bufs))) cand-bufs) nil t nil 'minibuffer-history (buffer-name (current-buffer)) t) Note: This repeats a suggestion I made on 2006-08-07 (Subject "`delete-windows-on' completion list should include only buffers that correspond to FRAME arg"). Richard rejected it, saying "It could be confusing for completion to fail to recognize a buffer name." How about reconsidering this decision now? 6. What about the return value more generally? Should it indicate whether any windows were actually deleted (nil/t)? Should it indicate how many were deleted (0..N)? Should we return a list of the actual deleted-window objects? I don't have a preference here. But if the return value is to be considered important, then (i) it should be documented and (ii) we might as well make the value more useful generally. 7. Putting 1-5 together: Why not a Lisp definition that does this: a. Do nothing if BUFFER is not an existing buffer or its name. Do not raise an error because of the BUFFER value in any case. b. Return nil in case (a) (no-buffer BUFFER). But we would continue to not document the return value. And we would fix any code (if there is any) that depends on the (undocumented) return value. c. Interactively, for reading BUFFER with completion, provide only names of buffers that are actually displayed. WDOT?