bug#59862: quit-restore per window buffer

["Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

martin rudalics via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

>> What about use cases where the frame was only spawned for that
>> particular window?
>>
>> For a frame focused setup frames mostly contain only one window and
>> don't close when the only window in it is killed
>
> Do you mean "window" or "buffer" here?  C-x 0 in a frame containing only
> one window gets you an "Attempt to delete minibuffer or sole ordinary
> window" error.  I suppose you meant "buffer" here.

I meant window. Same as you explain further below in your message
I call quit-window on a dedicate window the frame also dies with it.

>> leaving a window with
>> the scratch buffer around.
>
> Let's distinguish two different cases: If, after evaluating
>
> (custom-set-variables
>  '(display-buffer-alist '(("\\*info\\*" display-buffer-same-window)))
>  '(frame-auto-hide-function 'delete-frame))
>
> you do C-x 5 2 then C-h i and finally q, the second frame will stay
> around and show *scratch*.  Alternatively, you can evaluate
>
> (custom-set-variables
>  '(display-buffer-alist '(("\\*info\\*" display-buffer-same-window))))
>
> do C-x 5 2 then C-h i and finally C-u q which also kills the *info*
> buffer.  These are the behaviors needed for handling the Bug#12764
> scenario.
>
> If instead you evaluate
>
> (custom-set-variables
>  '(display-buffer-alist '(("\\*info\\*" display-buffer-pop-up-frame)))
>  '(frame-auto-hide-function 'delete-frame))
>
> and then do C-h i followed by q, the second frame gets deleted.
> Alternatively you can get the same visual behavior via
>
> (custom-set-variables
>  '(display-buffer-alist '(("\\*info\\*" display-buffer-pop-up-frame))))
>
> followed by C-h i and C-u q where the latter also kills the *info*
> buffer.
>
> In the thread of Bug#12764 I argued that deleting the frame would make
> sense in the first scenario too.  But then we would have to look into
> the history of the last window on that frame to decide whether the
> buffer it previously showed should be restored or not.  Even if there is
> no previous buffer for that window we should at least optionally allow
> the frame to stay alive.
>

I very much agree with you on that point.

I think if the window inside of a frame didn't contain any other buffer
than the initial buffer and a new buffer that uses the same window
there could be the argument that the window should die and thus the
frame too.