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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chris Hibbert <hibbert <at> mydruthers.com>
Cc: rudalics <at> gmx.at, 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 14:02:51 +0300

> Date: Mon, 16 Jun 2025 09:43:25 -0700
> Cc: 78785 <at> debbugs.gnu.org, shipmints <at> gmail.com
> From: Chris Hibbert <hibbert <at> mydruthers.com>
> 
> On 6/16/25 2:52 AM, Eli Zaretskii wrote:
> > There are two related, but different behaviors here, which both happen
> > when the current buffer is killed:
> > 
> >    . which buffer becomes the current one, and
> >    . which buffer replaces the current buffer in its window
> > 
> > The manual's documentation of the behavior of kill-buffer which you
> > quote talks about the former, whereas switch-to-prev-buffer-skip
> > affects the latter.
> 
> I'm confused by this explanation.

Confused in what sense?  In the sense that you cannot easily correlate
that to what you see in a running Emacs session?  That's because the
two processes I described happen one after the other, and users only
see the results of both of them.

My point is that there are two processes, and each one is controlled
by a different set of options and rules.  Conflating them into one, as
you tried to do, will only muddy the waters and make prediction of
what happens harder.

> 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.

It does, you just might not see it under some circumstances.

> 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.

That's because Emacs always forces the buffer of the selected window
to become the current buffer, when it (Emacs) displays the results of
killing the current buffer.  But before that happens, some other
buffer might become the current one.

> 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 don't think this is what happens in your case.

> > So I don't see a problem in the documentation, and AFAIU the
> > correction you suggested for the manual is incorrect, because it
> > wrongly conflates these two subtly different behaviors.
> 
> Martin's explanation is definitely an improvement on that.

I think it again conflates the two processes.  We need to describe
them separately, and in a way that clarifies that they are separate.
So if we decide to amend the manual, I'll try to come up with text
which emphasizes that aspect more clearly.

Meanwhile, I don't think I understand what was your practical problem
with kill-buffer.  Can you tell what you tried to achieve and what
information was missing in the documentation which would have helped
you do what you wanted?  Because this discussion started without a
clear description of the original problem (and the StackExchange
discussion doesn't clarify that, either).

Thanks.

Previous Next

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