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

View this message in rfc822 format

From: Johan Bockgård <bojohan <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 8184 <at> debbugs.gnu.org, 'tlh' <thunkout <at> gmail.com>, Drew Adams <drew.adams <at> oracle.com>
Subject: bug#8184: 23.1.90; `menu-bar-non-minibuffer-window-p' error in callsto	`kill-this-buffer'
Date: Sun, 27 Mar 2011 14:22:21 +0200

martin rudalics <rudalics <at> gmx.at> writes:

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

That can't happen. The *scratch* buffer is resurrected if all other
visible buffers disappear.

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

It's always possible to kill the current buffer, unless that buffer is
*scratch* and no other visible buffers exist.

Previous Next

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