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: delete-windows-on Date: Fri, 2 Oct 2009 10:37:14 -0700 Message-ID: <1EC435DE2A694911BE4AB26857D8C2C3@us.oracle.com> References: <8EA9172832C04915909AE7B506260481@us.oracle.com> 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 1254505113 10882 80.91.229.12 (2 Oct 2009 17:38:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 2 Oct 2009 17:38:33 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Juanma Barranquero'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 02 19:38:26 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 1Mtm4T-0000yT-NH for ged-emacs-devel@m.gmane.org; Fri, 02 Oct 2009 19:37:34 +0200 Original-Received: from localhost ([127.0.0.1]:60865 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mtm4S-0008Js-TD for ged-emacs-devel@m.gmane.org; Fri, 02 Oct 2009 13:37:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mtm4N-0008IR-Nw for emacs-devel@gnu.org; Fri, 02 Oct 2009 13:37:27 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mtm4I-0008A2-Vm for emacs-devel@gnu.org; Fri, 02 Oct 2009 13:37:27 -0400 Original-Received: from [199.232.76.173] (port=33450 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mtm4I-00089p-R1 for emacs-devel@gnu.org; Fri, 02 Oct 2009 13:37:22 -0400 Original-Received: from acsinet12.oracle.com ([141.146.126.234]:65335) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mtm4I-00080e-Ci for emacs-devel@gnu.org; Fri, 02 Oct 2009 13:37:22 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n92HaP2O025689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Oct 2009 17:36:26 GMT Original-Received: from abhmt002.oracle.com (abhmt002.oracle.com [141.146.116.11]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n92Hc0H5010081; Fri, 2 Oct 2009 17:38:00 GMT Original-Received: from dradamslap1 (/24.5.184.158) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Oct 2009 10:37:15 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcpDgN07MRHMv2eASKiPPzI4RpwprAAAD91w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt002.oracle.com [141.146.116.11] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A0B0209.4AC63A4C.0203: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:115856 Archived-At: > > 1. What "default buffer"? No such default is > > defined/implemented here, AFAICT. > > My mistake. > s/default/current/ No, my bad in this case. Prior to Emacs 23, BUFFER was not optional, and nil did not represent the current buffer. I had in mind the Emacs 21-22 treatment of nil - wasn't aware of the change. Dunno whether that change broke/breaks any code, but it is a user-observable behavior change. Prior to Emacs 23, (delete-windows-on nil) was a no-op; now it deletes windows on the current buffer. Since it is a user-visible change, it probably should be documented (e.g. in NEWS). Thanks for helping me become aware of this change. That doesn't affect my overall questions/suggestions, but it does affect the parts about nil BUFFER. > > 2. Besides, it is not the purpose of `delete-windows-on' to > > determine whether the BUFFER arg in fact corresponds to an > > existing buffer or someone just fucked > > up. Its purpose is to delete a window (or do nothing). > > No. Its purpose is to "[d]elete all windows showing BUFFER-OR-NAME." > An incorrect BUFFER-OR-NAME is an error. Yes to the first sentence. The second sentence is currently true, but (a) it's not documented and (b) it need not be true - I guess I disagree with that design choice. Why should it be an error? We have ways to check whether an object is a buffer - code can always do that. Why do that here also (in effect)? (And interactively there is no possibility of passing a non-buffer.) To me, it makes sense to treat 42 here the same way we treated nil in Emacs 21-22: a no-op. I'd sooner see both (a) a no-op here and (b) a return value that indicates what happened. But if the return value tells you nothing, then yes, there could be some value in raising an error. > > a. What to return, and whether the return value is significant > > (hence documented) or the function is instead called only for > > its side effect. > > In general, I prefer functions that clearly state what do they return, > even if it is always nil. It seems that that is the case here: nil is always returned. I have no problem with our documenting that. But it might be even better to return some useful info.