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

[martin rudalics <rudalics@gmx.at>]

 >   emacs -Q
 >   C-x 5 b foo RET
 >   C-x k RET
 >
 > This kills buffer foo and deletes the second frame.  Is this the
 > intended behavior?

Yes.

 > However, this use case looks inconsistent, or maybe I don't understand
 > the intended behavior:
 >
 >   emacs -Q
 >   C-x 5 b foo RET
 >
 > then in the new frame:
 >
 >   C-x b bar RET
 >   C-x b foo RET
 >   C-x k RET      (kills the foo buffer and shows bar)
 >   C-x k RET      (kills the bar buffer and shows *scratch*)
 >
 > My understanding of the intended behavior is that since foo and bar
 > are the only 2 buffers in that frame's buffer list, the frame should
 > be deleted after the last one of them is deleted.  But in fact the
 > frame stays alive and shows *scratch*.
 >
 > If I kill the buffers in the reverse order, i.e. bar first and then
 > foo, the frame does get deleted when foo is killed.

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

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?

martin