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

[martin rudalics <rudalics@gmx.at>]

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

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

You mean the "never had more than one buffer" one?

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

Detecting whether "the user switched buffers in that window" appears not
entirely trivial.  Earlier, I planned to divide functions into two
groups: The `switch-to-buffer' group would have been entirely left to
the user, while the `pop-to-buffer' group would have been left to the
applications.  In that case we could have made the `switch-to-buffer'
functions reset the quit-restore parameter.  Maybe we could achieve
something similar by testing `called-interactively-p' now.

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

`frame-auto-delete' is just a more general version of
`view-remove-frame-by-deleting'.  I'd use an option say
`window-auto-delete' with the values nil (for not deleting anything),
window (for deleting only a window and leaving a frame alone), frame
(for deleting only a frame and leaving a window alone), and t (for
deleting window and/or frame, whichever is applicable).

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

Anyway - let me shortly try to summarize the problem: Initially there
was a problem with help windows and view mode and the fact that it
wasn't possible to "exit" help windows cleanly.  I tried to solve that
back in 2007 using the `with-help-window' macro and the problems
disappeared.

Then two things happened: Stefan wanted me to rewrite the macro because
it contained ugly code.  And there were protests about `display-buffer'
not DTRT within `save-window-excursion'.  I tried to meet both issues by
installing the quit-restore window parameter (I didn't clean up any of
the window excursions yet though).

Now there are at quite a number of ways to get rid of a buffer in a
window: `bury-buffer', `kill-buffer' (which calls
`replace-buffer-in-windows'), `quit-window', and `delete-windows-on'
(the latter is interesting only in the special case where one of these
windows is the only window on its frame).  I tried to make them behave
in a consistent way which, however, might have been a bad idea in the
first place.

Note also that Stefan always favored a solution based on dedicated
windows: Such windows get automatically deleted and/or the frame
iconified.  But dedicated windows cannot handle the case where a window
got reused for showing the buffer and present difficulties when a window
shall be reused for showing another buffer.

Some of these problems might stem from the fact that `display-buffer' is
now used for creating fairly permanent windows (like when you call it
via `find-file' or `switch-to-buffer') and for fairly temporary windows
(like when you call it via `with-output-to-temp-buffer').  The expected
exit behavior of such windows seems different.

martin