Re: kill-buffer calls frame's buffer-predicate for all buffers even if the killed buffer was not shown in any window.

[Eli Zaretskii <eliz@gnu.org>]

> From: Constantin Kulikov <zxnotdead@gmail.com>
> Date: Mon, 16 Jan 2017 11:14:10 +0300
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> > it needs to find another buffer to become the current one
> The current in what sense? In the sense of 1)(current-buffer) or 2) (windown-buffer (selected-window))?

I meant 1), but it does 2) as well.

> If 1) then why require that this buffer is not visible?

Because it makes the most sense when kill-buffer is invoked
interactively.  Replacing the killed buffer with a buffer that is
displayed in some other window would be less useful than showing a
buffer not displayed anywhere else.

> What I understand of how kill-buffer must work:
> First call kill-buffer hooks
> Then find windows with the buffer and replace it, here the call to buffer-predicate it legit if the buffer was visible
> in any window.
> Then really kill the buffer.
> At this point we can set selected window buffer as current because we already have called the
> replace-buffer-in-window.
> If there is no selected window, then we can take the first buffer in (buffer-list) as current
> or create the *sctatch* and set it as current.

It sounds like you are assuming that current-buffer and the buffer
shown in the selected window are the same buffer.  But that doesn't
have to be true: a Lisp program could very well switch to another
buffer while doing its job.  And since Emacs must have a valid
current-buffer at all times, it must choose another one when the
current buffer is about to be killed.

> I can not see why there is a need to call buffer-predicate when killing a buffer that was not visible in any
> window.)

Once again, kill-buffer (and other-buffer, which kill-buffer calls,
and which actually calls the predicate) are interactive commands, so
their implementation is heavily biased towards doing what the user who
invoked these commands wants and expects.  I can see your point about
the same logic being of questionable value when with-temp-buffer kills
its temporary buffer, but I don't think we should consider changing
how kill-buffer and other-buffer work to make that use case more
efficient and its overhead smaller.  That's because these two commands
work like that for a very long time, and evidently do what the users
expect (the evidence being that I don't remember any complaints about
that).  So I'd suggest to leave these two commands alone, and instead
consider adding some new function, say kill-temp-buffer, which will
only do a small subset of what kill-buffer does, and disregard stuff
like visibility of candidate buffers to which current-buffer needs to
switch.