Subject: bug#8184: 23.1.90; `menu-bar-non-minibuffer-window-p' error in callsto `kill-this-buffer'

From: martin rudalics <[email-masked]>
Date: Mon, 07 Mar 2011 09:07:48 +0100

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

We might end up showing the *code-conversion-work* or *Echo Area* buffer
in a normal window which doesn't strike me as a good idea in response to
invoking a menu item called "Close".

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

I only tried to emulate the current behavior.  Usually, at least the
*scratch* or *Messages* buffer should be around so I suppose that in
practice it's always possible to kill the current buffer.

martin