bug#3302: Frame deletion with 'force fails

On May 17, 2009, at 4:31 PM, Stefan Monnier wrote:

>> In an Emacs -Q (recent CVS, NS port), doing the following right after
>> startup:
>
>>  (delete-frame (selected-frame) t)
>
>> will lead to an "Attempt to delete the only frame" error.  This seems
>> needless in non-X/non-Windows environments.
>
> I don't see the relationship with X/Window environments.
> What behavior woulod you like to see?  Would you like Emacs to exit in
> this case?  Or should it stick around until someone kills it?

Maybe I shouldn't have said non-X - I assumed that you couldn't  
receive events without a frame in X.  Maybe that's wrong.

The behavior would be that the application sticks around, may open a  
new frame (even automatically, when the minibuffer is used) when user  
interaction requires it.  After all, the menu bar may still be visible  
(doesn't need a frame).

I looked some more at the code (mainly by enabling frame deletion in  
this case), and because we expect there to be a selected frame pretty  
much at all times, I don't think this can be fixed.  (But I would hope  
I'm wrong.)
Does Emacs in daemon mode run with a special event loop?

I'd be happy for this to be closed as a "wontfix" bug, or if the  
delete-frame doc string was improved.