bug#59862: quit-restore per window buffer

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

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

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

martin