GNU bug report logs -
#71386
29.1; Frame is auto-deleted even when it has multiple tabs
Previous Next
Reported by: Al Haji-Ali <abdo.haji.ali <at> gmail.com>
Date: Thu, 6 Jun 2024 00:11:02 UTC
Severity: wishlist
Found in version 29.1
Fixed in version 31.0.50
Done: Juri Linkov <juri <at> linkov.net>
Bug is archived. No further changes may be made.
Full log
Message #59 received at 71386 <at> debbugs.gnu.org (full text, mbox):
>> 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
This bug report was last modified 34 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.