[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: martin rudalics
Subject: bug#8184: 23.1.90; `menu-bar-non-minibuffer-window-p' error in callsto `kill-this-buffer'
Date: Mon, 07 Mar 2011 09:07:48 +0100
User-agent: Thunderbird (Windows/20090302)

>> 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 
> 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 
> why s?he won't necessarily care that there is no other non-interesting buffer 
> display.  We should not prevent the user from killing the buffer (via the 

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]