emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: delete-other-frames


From: Richard Copley
Subject: Re: delete-other-frames
Date: Tue, 23 Aug 2016 20:55:17 +0100

On 23 August 2016 at 19:31, Eli Zaretskii <address@hidden> wrote:
>> From: Richard Copley <address@hidden>
>> Date: Tue, 23 Aug 2016 18:56:52 +0100
>> Cc: martin rudalics <address@hidden>, Emacs Development <address@hidden>
>>
>> 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 via email to

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