Subject: Re: bug#78785: 29.3; docs: switch-to-prev-buffer-skip is hard to find

From: martin rudalics <[email-masked]>
Date: Tue, 17 Jun 2025 12:57:46 +0200

> I'm confused by this explanation. When kill-buffer starts re-using
 > visible buffers, the statement "another buffer becomes current: one
 > that was current in the recent past but is not displayed in any window
 > now" doesn't seem true in any sense. When switch-to-prev-buffer-skip
 > is nil, even if there are other non-displayed buffers available, it
 > doesn't choose any of them, instead displaying one that's already
 > visible.

You're conflating two actions performed by 'kill-buffer':

- It first calls 'replace-buffer-in-windows' via

   replace_buffer_in_windows (buffer);

   to make sure that BUFFER is no more shown in any window.

- It then checks if BUFFER is the current buffer and if so makes another
   buffer current via

   if (b == current_buffer)
     {
       tem = Fother_buffer (buffer, Qnil, Qnil);
       Fset_buffer (tem);
       if (b == current_buffer)
	return Qnil;
     }

   If you look at the specification of 'other-buffer', you will see that
   the VISIBLE-OK argument is nil here, so replacing the current buffer
   does not choose a visible buffer unless all other buffers are visible
   and the doc is correct just as Eli said.

Eventually, the command loop will make the buffer of the selected window
current and that buffer may be indeed shown in any other window already.

You have to look into the documentations of 'replace-buffer-in-windows'
and 'switch-to-prev-buffer' to find out under which circumstances these
may show an already visible buffer.  The main reason is to accommodate
the following user behavior:

- The user types C-x 2 to look at two different portions of one and the
   same buffer.

- The users invokes a command to display a *Help* or *Info* buffer in
   one of these windows.

- The users kills the *Help* or *Info* buffer.

In this situation, our user expects that the original state before
invoking the help or info command gets restored thus showing the same
buffer in two windows.

As a rule, 'switch-to-prev-buffer' switches to a buffer previously shown
in that window.  If, in your case, this unwantedly shows the same buffer
in two windows, then the explanation usually is that the window that
showed the killed buffer did show the buffer it switched to before.

 > One plausible interpretation of "one that was current in the recent
 > past" is that there's a cache somewhere, and it gets exhausted. If
 > that were the case, I'd hope for access to or control of the size of
 > the cache. If there's no cache, then it should always be able to find
 > the non-visible buffers to use before the visible ones.

I can only repeat myself: Replacing the current buffer is not involved
in this scenario.  It's the selected window's buffer that gets replaced
and later made current by the command loop.

martin