GNU bug report logs - #80126
Fkill_buffer should not leave frame parameter 'buffer-list nil

Previous Next

To reply to this bug, email your comments to 80126 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stéphane Marks <shipmints <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Cc: martin rudalics <rudalics <at> gmx.at>
Subject: Fkill_buffer should not leave frame parameter 'buffer-list nil
Date: Sat, 3 Jan 2026 15:07:09 -0500

[Message part 1 (text/plain, inline)]

The following test produces the same results in batch as for a graphical
frame.

$ src/emacs -Q --batch --eval '(progn (defun msg () (message
"'\''buffer-list=%S cb=%S" (frame-parameter nil '\''buffer-list)
(current-buffer))) (msg) (kill-buffer "*scratch*") (msg))'

’buffer-list=(#<buffer *scratch*>) cb=#<buffer *scratch*>
’buffer-list=nil cb=#<buffer *Messages*>

I checked the code and it seems that in buffer.c, Fkill_buffer calls
frames_discard_buffer which can leave 'buffer-list nil as the test above
shows.

Shouldn't 'buffer-list have be updated with the newly selected buffer after
a successful call to replace_buffer_in_windows or its follow-on
replace_buffer_in_windows_safely?

-Stéphane

[Message part 2 (text/html, inline)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stéphane Marks <shipmints <at> gmail.com>,
 bug-gnu-emacs <at> gnu.org
Subject: Re: Fkill_buffer should not leave frame parameter 'buffer-list nil
Date: Sun, 4 Jan 2026 10:19:12 +0100

> I checked the code and it seems that in buffer.c, Fkill_buffer calls
> frames_discard_buffer which can leave 'buffer-list nil as the test above
> shows.

I think this is the correct behavior as long as no other buffer's window
gets selected in that frame.  WOW a frame's buffer list can be
legitimately nil.

> Shouldn't 'buffer-list have be updated with the newly selected buffer after
> a successful call to replace_buffer_in_windows or its follow-on
> replace_buffer_in_windows_safely?

This description

‘buffer-list’
     A list of buffers that have been selected in this frame, ordered
     most-recently-selected first.

is slightly inaccurate since strictly spoken we do not select buffers
but their windows ('other-buffer' uses a similar formulation).  Now the
only actor that can add a buffer to a frame's buffer list is
'select-window' via record_buffer.  'kill-buffer' can only remove a
buffer from that list.

Do you have an example where you would like to see at least one buffer
on one of these lists?

martin

Message #11 received at 80126 <at> debbugs.gnu.org (full text, mbox):

From: Stéphane Marks <shipmints <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 80126 <at> debbugs.gnu.org
Subject: Re: bug#80126: Fkill_buffer should not leave frame parameter
 'buffer-list nil
Date: Sun, 4 Jan 2026 05:42:11 -0500

[Message part 1 (text/plain, inline)]

On Sun, Jan 4, 2026 at 4:20 AM martin rudalics via Bug reports for GNU
Emacs, the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org> wrote:

>  > I checked the code and it seems that in buffer.c, Fkill_buffer calls
>  > frames_discard_buffer which can leave 'buffer-list nil as the test above
>  > shows.
>
> I think this is the correct behavior as long as no other buffer's window
> gets selected in that frame.  WOW a frame's buffer list can be
> legitimately nil.
>
>  > Shouldn't 'buffer-list have be updated with the newly selected buffer
> after
>  > a successful call to replace_buffer_in_windows or its follow-on
>  > replace_buffer_in_windows_safely?
>
> This description
>
> ‘buffer-list’
>       A list of buffers that have been selected in this frame, ordered
>       most-recently-selected first.
>
> is slightly inaccurate since strictly spoken we do not select buffers
> but their windows ('other-buffer' uses a similar formulation).  Now the
> only actor that can add a buffer to a frame's buffer list is
> 'select-window' via record_buffer.  'kill-buffer' can only remove a
> buffer from that list.
>
> Do you have an example where you would like to see at least one buffer
> on one of these lists?
>

At init time (and in the interactive case not the noninteractive case) is
where I'm seeing this condition and where I think "*scratch*" becomes the
implied selected buffer/window.

[Message part 2 (text/html, inline)]

Message #14 received at 80126 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stéphane Marks <shipmints <at> gmail.com>
Cc: 80126 <at> debbugs.gnu.org
Subject: Re: bug#80126: Fkill_buffer should not leave frame parameter
 'buffer-list nil
Date: Sun, 4 Jan 2026 12:23:27 +0100

>> Do you have an example where you would like to see at least one buffer
>> on one of these lists?
>>
>
> At init time (and in the interactive case not the noninteractive case) is
> where I'm seeing this condition and where I think "*scratch*" becomes the
> implied selected buffer/window.

Even if we did put it there, 'kill-buffer' could still reset it to nil.
Note that the purpose of these lists is to trace a user's activity with
respect to selecting windows.  Neither the initial value nor killing a
buffer should affect that.

martin

Message #17 received at 80126 <at> debbugs.gnu.org (full text, mbox):

From: Stéphane Marks <shipmints <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 80126 <at> debbugs.gnu.org, 80126-done <at> debbugs.gnu.org
Subject: Re: bug#80126: Fkill_buffer should not leave frame parameter
 'buffer-list nil
Date: Sun, 4 Jan 2026 06:29:26 -0500

[Message part 1 (text/plain, inline)]

On Sun, Jan 4, 2026 at 6:23 AM martin rudalics <rudalics <at> gmx.at> wrote:

>  >> Do you have an example where you would like to see at least one buffer
>  >> on one of these lists?
>  >>
>  >
>  > At init time (and in the interactive case not the noninteractive case)
> is
>  > where I'm seeing this condition and where I think "*scratch*" becomes
> the
>  > implied selected buffer/window.
>
> Even if we did put it there, 'kill-buffer' could still reset it to nil.
> Note that the purpose of these lists is to trace a user's activity with
> respect to selecting windows.  Neither the initial value nor killing a
> buffer should affect that.
>

Thanks for taking a look.  Closing this non-bug.

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.