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: martin rudalics <rudalics <at> gmx.at>
To: Johan Bockgård <bojohan <at> gnu.org>
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: Tue, 29 Mar 2011 10:31:52 +0200

>> 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 suppose by "visible buffer" you mean the object mentioned in the
comments of `kill-buffer' which is defined as the return value of
`other-buffer'.  That object is mystically unreliable here.  I can
easily crash my trunk by repeatedly killing all buffers.  But I was
never able to provide a presentable scenario so I just went ahead and
fixed this in my branch.

This said you're right that the scenario I described in the text you
cited shouldn't happen because `other-buffer' doesn't return a buffer
whose name starts with a space.

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

Ideally, yes.

martin

Previous Next

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