bug#71386: 29.1; Frame is auto-deleted even when it has multiple tabs

[martin rudalics]

>> So KILL is a boolean, and if it's non-nil, it means the buffer will be
>> killed?  If so, will the buffer be killed even if the function returns
>> non-nil?
>
> I don't know, I just copied the text from the doc string of 'window--delete'.
> But I don't understand the logic of using the KILL argument
> in 'window--delete':
>
>       (kill
>        (delete-frame frame))
>
> Maybe Martin could explain.

KILL non-nil here comes from the prefix argument of 'quit-window' which,
if provided, 'quit-window' passes as 'kill' via BURY-OR-KILL to
'quit-restore-window' which then passes t via the KILL argument to
'window--delete'.  'window--delete' itself does not deal with buffers,
it handles windows only.

'quit-restore-window' calls 'kill-buffer' later when BURY-OR-KILL equals
'kill'.  At that time, the window should already have been taken care of
- either by deletion or by showing another buffer.  The return value of
'window--delete' is used to make the last conjuncts in the first 'cond'
of 'quit-restore-window' succeed or fail (in the latter case the next
clause will be probed).

The idea of deleting the frame comes from the fact that a killed buffer
cannot be re-shown in that frame's sole window.  'quit-restore-window'
calls 'window--delete' in this case iff that window has no previous
other buffer to show instead, so deleting the window (and possibly its
frame) is the obvious choice rather than showing some unrelated buffer
in it.

martin