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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 04 Sep 2011 12:34:59 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 9419@debbugs.gnu.org
> 
>  >> 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.
> 
> It's around for almost four years by now and apparently nobody noticed
> the problem so far.

Then maybe we can live with it a bit longer.

>  > So I think the second alternative is the best, if it is doable.
> 
> You mean the "never had more than one buffer" one?

Yes.  But see below.

>  > On second though, if we are trying to fix the specific use case of
>  > save-window-excursion, why not solve it on the level of
>  > save-window-excursion?  That is, let save-window-excursion keep track
>  > of the window/frame created by display-buffer, and then delete that
>  > window/frame when the excursion ends.
>  >
>  > If this will solve the original problem, we can leave the behavior of
>  > kill-buffer etc. as it was in Emacs 23.
> 
> What I tried was not to fix the use case of `save-window-excursion'
> alone but handle that case just as if it were a special case of a help
> window.  Trying to handle the `save-window-excursion' case separately
> won't remove the "That sucks, IMO" case you bemoaned above.

You have convinced me now that a solution to the more general case is
orders of magnitude more complex for which TRT is not at all clear,
what with all the possible ways to create and get rid of windows,
whereas save-window-excursion is a very simple use case where the
correct behavior is both very clear and is probably simple to
implement.

So I'd say let's solve that, and leave the rest for a future version.

Stefan and Chong, would you please chime in and tell if you agree?