From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: RE: delete-windows-on Date: Sat, 03 Oct 2009 14:52:52 +0900 Message-ID: <877hvdhvm3.fsf@uwakimon.sk.tsukuba.ac.jp> References: <8EA9172832C04915909AE7B506260481@us.oracle.com> <4AC637A3.3070305@gmx.at> <47CD9C0ADBDC44CDA748F4978DF90DFE@us.oracle.com> <240EE4A03D004CFAA04A4B9AAC3EAD70@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1254548640 20784 80.91.229.12 (3 Oct 2009 05:44:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 3 Oct 2009 05:44:00 +0000 (UTC) Cc: 'martin rudalics' , emacs-devel@gnu.org, 'Juanma Barranquero' To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 03 07:43:52 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 1MtxPM-0006cQ-Dr for ged-emacs-devel@m.gmane.org; Sat, 03 Oct 2009 07:43:52 +0200 Original-Received: from localhost ([127.0.0.1]:40569 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MtxPL-00049u-Kt for ged-emacs-devel@m.gmane.org; Sat, 03 Oct 2009 01:43:51 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MtxPD-00049j-JT for emacs-devel@gnu.org; Sat, 03 Oct 2009 01:43:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MtxP8-00048Y-Is for emacs-devel@gnu.org; Sat, 03 Oct 2009 01:43:42 -0400 Original-Received: from [199.232.76.173] (port=42890 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MtxP8-00048V-3b for emacs-devel@gnu.org; Sat, 03 Oct 2009 01:43:38 -0400 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:54740) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MtxP7-0000J2-JQ for emacs-devel@gnu.org; Sat, 03 Oct 2009 01:43:37 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id 606CC1535AF; Sat, 3 Oct 2009 14:43:35 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 21B1E12811B; Sat, 3 Oct 2009 14:52:53 +0900 (JST) In-Reply-To: <240EE4A03D004CFAA04A4B9AAC3EAD70@us.oracle.com> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" 02b7c7189041+ XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:115876 Archived-At: Drew Adams writes: > Let me summarize the current state of the discussion and my > questions/suggestions: 1 & 2 omitted. > 3. Emacs 23 always returns nil. Dunno what the case was before > 23. I don't have a problem with it always returning nil. > > I did suggest that we might instead return something indicating > whether a window was actually deleted, similarly to how > `kill-buffer' lets you know whether it killed the buffer. But this > suggestion is not so important. My personal preference here is no; code that doesn't accept the possibility of a dead window error should check window-live-p. But the analogy with kill-buffer is appropriate. So I guess that's a -0. 4 omitted. > 5. Raising an error for a string that does not name an existing > buffer is wrong, IMO. No other opinions expressed about this, so far. AFAICS such a string is a programming error, because (as you've pointed out yourself) interactively the user must specify an existing buffer. Such errors should be raised as early as possible. If you have a use case, please specify it. For now, I'm strongly in favor of raising an error. > 6. I suggested that for interactive use the completion candidates > be limited to buffers that actually have windows. No other > opinions expressed about this, so far. +0.5. I'm not sure it's worth the programming effort, but I see no harm in it.