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: bug#8184: 23.1.90; `menu-bar-non-minibuffer-window-p' error in callsto `kill-this-buffer' Date: Sun, 6 Mar 2011 11:36:30 -0800 Message-ID: References: <4D73D021.8070105@gmx.at> <4D73DCF0.9080604@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1299445674 31867 80.91.229.12 (6 Mar 2011 21:07:54 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 6 Mar 2011 21:07:54 +0000 (UTC) Cc: 8184@debbugs.gnu.org, 'tlh' To: "'martin rudalics'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Mar 06 22:07:49 2011 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.69) (envelope-from ) id 1PwLB6-0007se-Le for geb-bug-gnu-emacs@m.gmane.org; Sun, 06 Mar 2011 22:07:49 +0100 Original-Received: from localhost ([127.0.0.1]:43369 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PwKlL-0001iS-4x for geb-bug-gnu-emacs@m.gmane.org; Sun, 06 Mar 2011 15:41:11 -0500 Original-Received: from [140.186.70.92] (port=40327 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PwKjk-0001Rg-Dw for bug-gnu-emacs@gnu.org; Sun, 06 Mar 2011 15:41:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PwKE9-0007J9-Eb for bug-gnu-emacs@gnu.org; Sun, 06 Mar 2011 15:06:54 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:50968) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PwKE9-0007Iy-CC for bug-gnu-emacs@gnu.org; Sun, 06 Mar 2011 15:06:53 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1PwJnC-00016B-QJ; Sun, 06 Mar 2011 14:39:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Mar 2011 19:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8184 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 8184-submit@debbugs.gnu.org id=B8184.12994403024173 (code B ref 8184); Sun, 06 Mar 2011 19:39:02 +0000 Original-Received: (at 8184) by debbugs.gnu.org; 6 Mar 2011 19:38:22 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PwJmY-00015G-3N for submit@debbugs.gnu.org; Sun, 06 Mar 2011 14:38:22 -0500 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PwJmW-000154-BD for 8184@debbugs.gnu.org; Sun, 06 Mar 2011 14:38:20 -0500 Original-Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p26JcDGw007560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 6 Mar 2011 19:38:14 GMT Original-Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p26JcCUi010530; Sun, 6 Mar 2011 19:38:12 GMT Original-Received: from abhmt007.oracle.com by acsmt354.oracle.com with ESMTP id 1112909411299440191; Sun, 06 Mar 2011 11:36:31 -0800 Original-Received: from dradamslap1 (/10.159.53.25) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 06 Mar 2011 11:36:31 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4D73DCF0.9080604@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 thread-index: AcvcMqVNCfS1iHgjTp+afG4f9nOH6AAAFpWQ X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4D73E2A5.0011,ss=1,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sun, 06 Mar 2011 14:39:02 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org 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:44709 Archived-At: > >> (defun kill-this-buffer-enabled-p () > >> (or (not (menu-bar-non-minibuffer-window-p)) > >> (let (found-1) > >> (catch 'found-2 > >> (dolist (buffer (buffer-list)) > >> (unless (string-match-p "^ " (buffer-name buffer)) > >> (if (not found-1) > >> (setq found-1 t) > >> (throw 'found-2 t)))))))) > > The idea is that at least _two_ interesting buffers are > needed to enable `kill-this-buffer'. Right, that's the existing behavior. But why? Why shouldn't menu item `Close' be available to kill the current buffer even if it is the only "interesting" buffer? I imagine the answer behind this design is that we never want to show an uninteresting buffer - or that we never want to replace an interesting one by an uninteresting one in the same window. I don't think that's a good idea. (I mistakenly thought you were trying to improve this at the same time as improving the performance - see below.) `Close' is about killing the buffer. It is not just or even primarily about replacing it with another in the window. I'd say we should let the user kill the buffer even if it is the only "interesting" one. A user will wonder (bad UI) why `Close' isn't available in this case, and even if s?he correctly guesses why s?he won't necessarily care that there is no other non-interesting buffer to display. We should not prevent the user from killing the buffer (via the menu). Just one opinion. Another alternative could be to let `Close' be enabled in this case but also close (delete) the window if the buffer killed was the last "interesting" one. (But my preference would be to just kill the buffer, even in this case.) > found-1 is initially nil and set to t when the > first interesting buffer is found. The throw to found-2 > occurs when the second interesting buffer has been found. Yes, your indentation threw me off (probably from pasting TAB chars). It looked like you were throwing in any case (outside the `if'). I thus thought you were also proposing the behavior improvement of letting the user kill the last "interesting" buffer.