GNU bug report logs - #3302
Frame deletion with 'force fails

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 3302 in the body.
You can then email your comments to 3302 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Reitter <david.reitter <at> gmail.com>
To: emacs-pretest-bug <at> gnu.org
Subject: Frame deletion with 'force fails
Date: Fri, 15 May 2009 17:48:50 -0700

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.

Message #10 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: David Reitter <david.reitter <at> gmail.com>
Cc: 3302 <at> debbugs.gnu.org, emacs-pretest-bug <at> gnu.org
Subject: Re: bug#3302: Frame deletion with 'force fails
Date: Sun, 17 May 2009 16:31:55 -0400

> 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

Message #20 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Reitter <david.reitter <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 3302 <at> debbugs.gnu.org, emacs-pretest-bug <at> gnu.org
Subject: Re: bug#3302: Frame deletion with 'force fails
Date: Sun, 17 May 2009 22:41:43 -0400

[Message part 1 (text/plain, inline)]

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.

[smime.p7s (application/pkcs7-signature, attachment)]

Message #30 received at 3302 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: David Reitter <david.reitter <at> gmail.com>
Cc: 3302 <at> debbugs.gnu.org
Subject: Re: bug#3302: Frame deletion with 'force fails
Date: Sun, 17 May 2009 23:51:16 -0400

> 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

Message #35 received at 3302 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Reitter <david.reitter <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 3302 <at> debbugs.gnu.org
Subject: Re: bug#3302: Frame deletion with 'force fails
Date: Sun, 17 May 2009 23:58:23 -0400

[Message part 1 (text/plain, inline)]

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.

[smime.p7s (application/pkcs7-signature, attachment)]

Message #40 received at 3302 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Reitter <david.reitter <at> gmail.com>
To: 3302 <at> debbugs.gnu.org
Cc: 3302-done <at> debbugs.gnu.org
Subject: closing this
Date: Fri, 22 May 2009 00:07:27 -0400

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

Message #50 received at 3302 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jason Rumney <jasonr <at> gnu.org>
To: David Reitter <david.reitter <at> gmail.com>, 3302 <at> debbugs.gnu.org
Subject: Re: bug#3302: closing this
Date: Fri, 22 May 2009 12:58:02 +0800

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?

Previous Next

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