bug#9419: 24.0.50; C-x k deletes the entire frame instead of switching to another buffer

[Eli Zaretskii]

> Date: Sat, 03 Sep 2011 19:29:29 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 9419@debbugs.gnu.org
> 
>  >> (save-window-excursion
>  >>    (display-buffer "foo"))
>  >>
>  >> which doesn't DTRT when foo is displayed on a different frame.
>  >
>  > You mean, if display-buffer creates a new frame?  Or that frame
>  > already exists, and display-buffer just raises it and makes it the
>  > selected frame?
>  >
>  > And what do you mean by "doesn't DTRT"?  What is TRT in that case?
> 
> In the idiom above, when a user has `pop-up-frames' nil, a new window
> showing the buffer gets created on the selected frame and gets deleted
> when the window excursion terminates.  When a user has `pop-up-frames'
> non-nil and a new frame gets created that frame is not deleted.  This
> fact has already caused some vivid discussions here.  IMO TRT is to
> treat windows and frames the same.

Agreed.

>  > Perhaps I'm missing something, but if we are talking about "long time
>  > after", then which buffer causes frame deletion is immaterial: they
>  > both will cause the same amount of surprise.
> 
> Precisely this mechanism is inherent to help frames you quit with "q" in
> Emacs 23.  Quitting any other buffer in such a frame would not cause its
> deletion.

That sucks, IMO.

>  > This is actually how I bumped into this problem in the first place.  I
>  > have a frame where I switch between different *info*<n> buffers
>  > showing various manuals, using the info-display-manual command.
>  > Whenever the Emacs or ELisp manuals are rebuilt (because they are
>  > updated on the trunk), I kill the corresponding buffer and re-read
>  > that manual anew.  When I started using Emacs 24, I was surprised to
>  > find out that this sometimes, but not always, deleted the entire
>  > frame.  I now understand that this depends on which buffer I was
>  > killing and in what order, but believe me: the surprise was complete,
>  > and the apparently inconsistent behavior only added to it.
> 
> You should have protested immediately.

Believe it or not, this bug report is my "immediate" protest ;-)  It
took time for me to realize that the frame deletion was not due to
some cockpit error on my part, and then some more time to create a
simple recipe suitable for submission.

>  > I can see 3 possible ways to have a consistent behavior:
>  >
>  >  . Never delete a frame except by an explicit call to delete-frame.  I
>  >    think this is what Emacs 23 did, so it is also backward-compatible.
> 
> There are two exceptions in Emacs 23 to this rule - help frames and
> dedicated frames.
> 
>  >  . A minor variation on the above: never delete a frame, except when
>  >    it was created by display-buffer, and never had more than one
>  >    buffer in its buffer list.  IIUC the use case you were trying to
>  >    fix, this will fix it.
> 
> Tracking the "never had more than one buffer" is tedious but could be
> done.
> 
>  >  . Always delete a frame whenever the last buffer in its buffer list
>  >    is killed.  This is a change in behavior wrt Emacs 23, so it should
>  >    probably be conditional on some option.
> 
> It is: Setting `frame-auto-delete' to nil should inhibit implicit
> deletion of frames.

So I think the second alternative is the best, if it is doable.

> But it won't inhibit implicit deletion of windows, something hardly
> anyone has noticed (Juanma is the only one who suffers from it so
> far).

I did notice that.  I just didn't yet make up my mind whether I like
it or not.

> I can do whatever people want.  But consistency should also cover the
> window/frame dichotomy.

Agreed.

So how about this plan:

  . Never delete a frame, except when it was created by
    display-buffer, and never had more than one buffer in its buffer
    list.

  . Do the same with windows created by display-buffer: if the user
    switched buffers in that window, don't delete the window when the
    excursion ends.

  . Introduce a window-auto-delete option, by default set the same as
    frame-auto-delete, to control window deletion like
    frame-auto-delete controls that of frames.  Alternatively,
    deprecate frame-auto-delete and introduce a new
    frame-and-window-auto-delete with the old one its alias.  Then
    make this new option control both window and frame auto-deletion
    alike.