bug#3302: Frame deletion with 'force fails

bug#3302: Frame deletion with 'force fails

[David Reitter]

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.

frame.c, delete_frame():
   /* x_connection_closed must have set FORCE to `noelisp' in order
      to delete the last frame, if it is gone.  */
   if (NILP (XCDR (Vframe_list)) && !EQ (force, Qnoelisp))
     error ("Attempt to delete the only frame");

If there are technical reasons for this, it would be good if the doc  
string for `delete-frame' was updated.

bug#3302: Frame deletion with 'force fails

[Stefan Monnier]

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


        Stefan

bug#3302: Frame deletion with 'force fails

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]

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.



[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

bug#3302: Frame deletion with 'force fails

[Stefan Monnier]

> After all, the menu bar may still be visible (doesn't need a frame).

Oh, I see.  Yes, under NS it might make sense.

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

It's easy to fix: just provide some special frame for it (one that
isn't displayed).

> Does Emacs in daemon mode run with a special event loop?

No.  But it has a special terminal (to a large extent, the same as used
for --batch mode), so it does have a "selected-frame".

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

I'm not opposed to installing NS-specific changes to address this
problem, but they will need to be made elsewhere since, as you've
noticed, too much of the code relies on the existence of
a selected-frame.


        Stefan

bug#3302: Frame deletion with 'force fails

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 488 bytes --]

On May 17, 2009, at 11:51 PM, Stefan Monnier wrote:
>> 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.)
>
> It's easy to fix: just provide some special frame for it (one that
> isn't displayed).

Yes, that's what we've been doing in Emacs 22.  Now, #3303 prevents  
it.  See discussion there.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

bug#3302: closing this

[David Reitter]

I am closing this bug as it is unlikely we're going to fix this  
problem any time soon.

At least one frame needs to be declared selected, and that frame may  
be hidden, which provides the workaround for this problem (as in  
previous versions).

bug#3302: marked as done (Frame deletion with 'force fails)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 846 bytes --]


Your message dated Fri, 22 May 2009 00:07:27 -0400
with message-id <5CAA97B0-1C7F-449D-AAEC-89499A8B8583@gmail.com>
and subject line closing this
has caused the Emacs bug report #3302,
regarding Frame deletion with 'force fails
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
3302: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3302
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 3773 bytes --]

From: David Reitter <david.reitter@gmail.com>
To: emacs-pretest-bug@gnu.org
Subject: Frame deletion with 'force fails
Date: Fri, 15 May 2009 17:48:50 -0700
Message-ID: <F46AC1EA-C47D-4A0D-B6A6-C89C1F6BFA67@gmail.com>

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.

frame.c, delete_frame():
   /* x_connection_closed must have set FORCE to `noelisp' in order
      to delete the last frame, if it is gone.  */
   if (NILP (XCDR (Vframe_list)) && !EQ (force, Qnoelisp))
     error ("Attempt to delete the only frame");

If there are technical reasons for this, it would be good if the doc  
string for `delete-frame' was updated.






[-- Attachment #3: Type: message/rfc822, Size: 2693 bytes --]

From: David Reitter <david.reitter@gmail.com>
To: 3302@emacsbugs.donarmstrong.com
Cc: 3302-done@emacsbugs.donarmstrong.com
Subject: closing this
Date: Fri, 22 May 2009 00:07:27 -0400
Message-ID: <5CAA97B0-1C7F-449D-AAEC-89499A8B8583@gmail.com>

I am closing this bug as it is unlikely we're going to fix this  
problem any time soon.

At least one frame needs to be declared selected, and that frame may  
be hidden, which provides the workaround for this problem (as in  
previous versions).

bug#3302: closing this

[Jason Rumney]

David Reitter wrote:
> I am closing this bug as it is unlikely we're going to fix this 
> problem any time soon.

That doesn't seem like a good reason to close it. What is wrong with 
leaving it open so that sometime after "soon" it can be fixed properly?