GNU bug report logs - #8184
23.1.90; `menu-bar-non-minibuffer-window-p' error in calls to `kill-this-buffer'

Previous Next

Full log

View this message in rfc822 format

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 'Eli Zaretskii' <eliz <at> gnu.org>, 8184 <at> debbugs.gnu.org, 'tlh' <thunkout <at> gmail.com>
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

>  >> (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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.