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

[martin rudalics]

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