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

[martin rudalics]

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

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.

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

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

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

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

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

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

martin