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

[martin rudalics]

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