From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: kill-buffer calls frame's buffer-predicate for all buffers even if the killed buffer was not shown in any window. Date: Mon, 16 Jan 2017 18:26:55 +0200 Message-ID: <83d1fn9dio.fsf@gnu.org> References: <83inpg9ib5.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1484584106 25720 195.159.176.226 (16 Jan 2017 16:28:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 16 Jan 2017 16:28:26 +0000 (UTC) Cc: emacs-devel@gnu.org To: Constantin Kulikov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 16 17:28:20 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cTA8X-0004jl-8y for ged-emacs-devel@m.gmane.org; Mon, 16 Jan 2017 17:28:01 +0100 Original-Received: from localhost ([::1]:58035 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cTA8b-0005Qz-VD for ged-emacs-devel@m.gmane.org; Mon, 16 Jan 2017 11:28:06 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51774) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cTA7c-0005Pl-Ko for emacs-devel@gnu.org; Mon, 16 Jan 2017 11:27:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cTA7Y-0006rr-M3 for emacs-devel@gnu.org; Mon, 16 Jan 2017 11:27:04 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:52567) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cTA7Y-0006rl-JP; Mon, 16 Jan 2017 11:27:00 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3391 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cTA7X-0002WE-Sf; Mon, 16 Jan 2017 11:27:00 -0500 In-reply-to: (message from Constantin Kulikov on Mon, 16 Jan 2017 11:14:10 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:211328 Archived-At: > From: Constantin Kulikov > Date: Mon, 16 Jan 2017 11:14:10 +0300 > Cc: emacs-devel > > > 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.