GNU bug report logs - #78785
29.3; docs: switch-to-prev-buffer-skip is hard to find

Previous Next

Full log

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

From: martin rudalics <rudalics <at> gmx.at>
To: Chris Hibbert <hibbert <at> mydruthers.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 78785 <at> debbugs.gnu.org, shipmints <at> gmail.com
Subject: Re: bug#78785: 29.3; docs: switch-to-prev-buffer-skip is hard to find
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

Previous Next

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