unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Richard Copley <rcopley@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: martin rudalics <rudalics@gmx.at>,
	Emacs Development <emacs-devel@gnu.org>
Subject: Re: delete-other-frames
Date: Tue, 23 Aug 2016 20:55:17 +0100	[thread overview]
Message-ID: <CAPM58ojSw3F9Y+nmh+zr+HVgd8JfXd-g3R3NZCmGaJi8Y79L3Q@mail.gmail.com> (raw)
In-Reply-To: <83a8g3fibf.fsf@gnu.org>

On 23 August 2016 at 19:31, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Tue, 23 Aug 2016 18:56:52 +0100
>> Cc: martin rudalics <rudalics@gmx.at>, Emacs Development <emacs-devel@gnu.org>
>>
>> C-x b * RET ;; create and switch to buffer "*"
>> M-x ediff-buffers RET RET RET ;; ediff buffers "*" and "*scratch*"
>> ;; Now attempt to close the main Emacs frame using the window manager
>>
>> This gives:
>>
>> Debugger entered--Lisp error: (error "Attempt to delete a surrogate
>> minibuffer frame")
>>   delete-frame(#<frame *scratch* 00000004009c5870> t)
>>   handle-delete-frame((delete-frame (#<frame *scratch* 00000004009c5870>)))
>>   funcall-interactively(handle-delete-frame (delete-frame (#<frame
>> *scratch* 00000004009c5870>)))
>>   call-interactively(handle-delete-frame nil [(delete-frame (#<frame
>> *scratch* 00000004009c5870>))])
>>   command-execute(handle-delete-frame nil [(delete-frame (#<frame
>> *scratch* 00000004009c5870>))] t)
>>   read-event(nil t 2)
>>   sit-for(2)
>>   execute-extended-command(nil "toggle-debug-on-error" "t-d-o-e")
>>   funcall-interactively(execute-extended-command nil
>> "toggle-debug-on-error" "t-d-o-e")
>>   call-interactively(execute-extended-command nil nil)
>>   command-execute(execute-extended-command)
>>
>> I've never been sure whether this deserves a bug report, or what
>> should be the expected behaviour.
>
> If we don't know what should be the correct behavior, how can we fix
> this?

Yes, we would need to decide what behaviour to implement.
Now that I come to think about it, my tentative suggestion is:
a close command to the last non-minibuffer-only frame
should have the same effect as C-x C-c.

>> FWIW when this happens my intention is usually to kill Emacs.
>
> But there are more than one frame in this case, so closing one of them
> can never kill Emacs anyway, even if the frame you want to delete will
> be deleted.

Yeah, but I wouldn't put it like that, just that it doesn't kill Emacs
the way things are now. Unless I'm misunderstanding you.

> As with any multi-window program, closing one window normally doesn't
> exit the program.

For programs with multiple top-level document windows, that's true.
On the other hand, programs with floating toolbar windows such as
Paint.NET don't make you close all the toolbars as well as the main
window. But that's not very helpful of me, because Emacs isn't the
same as either of those things.



  reply	other threads:[~2016-08-23 19:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-23  8:19 delete-other-frames martin rudalics
2016-08-23 14:09 ` delete-other-frames Eli Zaretskii
2016-08-23 17:56   ` delete-other-frames Richard Copley
2016-08-23 18:31     ` delete-other-frames Eli Zaretskii
2016-08-23 19:55       ` Richard Copley [this message]
2016-08-24  9:07     ` delete-other-frames martin rudalics
2016-08-24  9:06   ` delete-other-frames martin rudalics
2016-08-25  9:16     ` delete-other-frames martin rudalics
2016-08-25 14:46       ` delete-other-frames Eli Zaretskii
2016-08-27  1:32         ` delete-other-frames Richard Stallman
2016-08-27  7:40           ` delete-other-frames Eli Zaretskii
     [not found]         ` <<E1bdSUT-00059T-8W@fencepost.gnu.org>
2016-08-27  6:31           ` delete-other-frames Drew Adams
2016-08-27  7:45             ` delete-other-frames Eli Zaretskii
2016-08-27 21:45             ` delete-other-frames Richard Stallman
     [not found]           ` <<49a2a9c7-8573-4f07-897f-3eb444679d8a@default>
     [not found]             ` <<E1bdlPn-0005Ch-I4@fencepost.gnu.org>
2016-08-28  0:41               ` delete-other-frames Drew Adams
     [not found] <<<57BC072F.9070704@gmx.at>
     [not found] <<57BC072F.9070704@gmx.at>

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPM58ojSw3F9Y+nmh+zr+HVgd8JfXd-g3R3NZCmGaJi8Y79L3Q@mail.gmail.com \
    --to=rcopley@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).