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 15:54:35 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 9419@debbugs.gnu.org
> 
> The problem I originally wanted to solve is the following idiom
> 
> (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?

> My intention was to solve this with the help of the quit-restore
> window parameter (similar to the quit mechanism of help windows in
> Emacs 23).  For that purpose the buffer shown in the corresponding
> window must be the same as when the window was created in order to
> rule out cases where the user long time after doing the original
> display quits the window showing some different buffer in some way
> and gets surprised by the deletion of the window.

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.

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.

> I can remove this restriction and kill the buffer in the "kill foo first
> and bar afterwards" scenario too, but then I will delete a window always
> when all buffers I've ever shown in it have gone.  What do you mean?

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.

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

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

Anything else is inconsistent, IMO, and inconsistency is always worse
than any consistent alternative, in my experience.

Thanks.