[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: Tue, 29 Mar 2011 10:31:52 +0200
User-agent: Thunderbird (Windows/20090302)

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


reply via email to

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