[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 2.0.0.21 (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
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
- bug#8184: 23.1.90; `menu-bar-non-minibuffer-window-p' error in calls to `kill-this-buffer', tlh, 2011/03/06
- bug#8184: 23.1.90; `menu-bar-non-minibuffer-window-p' error in calls to `kill-this-buffer', Eli Zaretskii, 2011/03/06
- bug#8184: 23.1.90; `menu-bar-non-minibuffer-window-p' error in calls to `kill-this-buffer', martin rudalics, 2011/03/06
- bug#8184: 23.1.90; `menu-bar-non-minibuffer-window-p' error in callsto `kill-this-buffer', Drew Adams, 2011/03/06
- bug#8184: 23.1.90; `menu-bar-non-minibuffer-window-p' error in callsto `kill-this-buffer', martin rudalics, 2011/03/06
- bug#8184: 23.1.90; `menu-bar-non-minibuffer-window-p' error in callsto `kill-this-buffer', Drew Adams, 2011/03/06
- bug#8184: 23.1.90; `menu-bar-non-minibuffer-window-p' error in callsto `kill-this-buffer',
martin rudalics <=
- bug#8184: 23.1.90; `menu-bar-non-minibuffer-window-p' error in callsto `kill-this-buffer', Drew Adams, 2011/03/07
- bug#8184: 23.1.90; `menu-bar-non-minibuffer-window-p' error in callsto `kill-this-buffer', Johan Bockgård, 2011/03/27
- bug#8184: 23.1.90; `menu-bar-non-minibuffer-window-p' error in callsto `kill-this-buffer', martin rudalics, 2011/03/29
- bug#8184: 23.1.90; `menu-bar-non-minibuffer-window-p' error in calls to `kill-this-buffer', Stefan Monnier, 2011/03/06
- bug#8184: 23.1.90; `menu-bar-non-minibuffer-window-p' error in calls to `kill-this-buffer', martin rudalics, 2011/03/07