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

Message #26 received at 8184 <at> debbugs.gnu.org (full text, mbox):

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

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

Previous Next

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