From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#66117: 30.0.50; `find-buffer-visiting' is slow when opening large number of buffers Date: Sun, 17 Dec 2023 14:14:55 +0200 Message-ID: <83le9tja9s.fsf@gnu.org> References: <878r919qfh.fsf@localhost> <83fs06rz10.fsf@gnu.org> <87fs06w4ui.fsf@localhost> <83bkaurut9.fsf@gnu.org> <87o7esq319.fsf@localhost> <83bkasrb3f.fsf@gnu.org> <83wmtgpuyf.fsf@gnu.org> <871qboprh3.fsf@localhost> <87y1dwobey.fsf@localhost> <878r5v20gu.fsf@localhost> <83bkapl5zh.fsf@gnu.org> <83zfy9jkoh.fsf@gnu.org> <878r5tglwp.fsf@localhost> <83ttohjet0.fsf@gnu.org> <8734w114pa.fsf@localhost> <83r0jljdoa.fsf@gnu.org> <87r0jlysrf.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28797"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dmitry@gutov.dev, 66117@debbugs.gnu.org, mattias.engdegard@gmail.com, monnier@iro.umontreal.ca To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 17 13:16:13 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rEq45-0007Ku-G8 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 17 Dec 2023 13:16:13 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rEq41-0004rE-VN; Sun, 17 Dec 2023 07:16:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rEq3t-0004qk-9M for bug-gnu-emacs@gnu.org; Sun, 17 Dec 2023 07:16:01 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rEq3t-0000lh-0t for bug-gnu-emacs@gnu.org; Sun, 17 Dec 2023 07:16:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rEq3u-0004rC-6V for bug-gnu-emacs@gnu.org; Sun, 17 Dec 2023 07:16:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Dec 2023 12:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66117 X-GNU-PR-Package: emacs Original-Received: via spool by 66117-submit@debbugs.gnu.org id=B66117.170281535017455 (code B ref 66117); Sun, 17 Dec 2023 12:16:02 +0000 Original-Received: (at 66117) by debbugs.gnu.org; 17 Dec 2023 12:15:50 +0000 Original-Received: from localhost ([127.0.0.1]:56689 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rEq3h-0004WH-JP for submit@debbugs.gnu.org; Sun, 17 Dec 2023 07:15:50 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37394) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rEq3f-0004Hp-AJ for 66117@debbugs.gnu.org; Sun, 17 Dec 2023 07:15:48 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rEq3X-0000hm-SB; Sun, 17 Dec 2023 07:15:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=tZ/RihUcVvDckY2vg25HqFrS1aeOSedFn1FhWfDJPfY=; b=M2A7hZuXYdH4pMSR7vD6 dBOAwWteBeISuk+UT/P/gnijnp6BY8LU3TH6dfuLa6v5jOJeX/0XZMm0YH95KSCmgDoFyz7in6NlX lI9EcyvpaPMUpsaWZS1BkSVs1SCJa22waqay2c36dx8NxmBYt2fkrsT4GWl8LXGWT/vGle6R+DA6h btTgfyF4FX4Ijs0x7uEM0IOaNCR6XrCFavAT6v22QFPlro2KusBPTMZ8c72yhXaqSrbzgZ9YwuprS 8hx0H4rXNqYXCKBBf5+fljjMMBmFy9n1w3gTL3yCxsWAqwjOuuixVVm1dydrCJKp3HEOZk6+n/tnD lpexKFa9FJPIQw==; In-Reply-To: <87r0jlysrf.fsf@localhost> (message from Ihor Radchenko on Sun, 17 Dec 2023 11:26:28 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:276421 Archived-At: > From: Ihor Radchenko > Cc: monnier@iro.umontreal.ca, dmitry@gutov.dev, 66117@debbugs.gnu.org, > mattias.engdegard@gmail.com > Date: Sun, 17 Dec 2023 11:26:28 +0000 > > Eli Zaretskii writes: > > >> > Maybe I'm confused, but won't this change have at least _some_ effect > >> > on Lisp programs? For example, what about this fragment from the > >> > ELisp manual, which describes the effect of > >> > make-variable-buffer-local: > >> > > >> > A peculiar wrinkle of this feature is that binding the variable > >> > (with ‘let’ or other binding constructs) does not create a > >> > buffer-local binding for it. Only setting the variable (with ‘set’ > >> > or ‘setq’), while the variable does not have a ‘let’-style binding > >> > that was made in the current buffer, does so. > >> > > >> > Will this case work the same after the change as it did before? > >> > >> I read this differently > > > > Differently from what? > > AFAIU, you are concerned that my call to Fmake_variable_buffer_local may > have unexpected side effects because make-variable-buffer-local can be > tricky, as stated in the quoted paragraph. > But it is not how I read this. > > Or did you mean something else? I meant to ask whether the behavior with case-fold-search before your changes in the context of the above situation differs from its behavior after the changes. > > >> - when you have > >> > >> (let ((var 'val)) > >> (make-variable-buffer-local 'var)) > >> > >> it will not set buffer-local value to 'val. > > > > And before the patch what would have happened? > > I did not make changes to `make-variable-buffer-local' in the patch. > Nothing changed there. I just wanted to make sure that we understand > that paragraph the same way - that `make-variable-buffer-local' has > "wrinkle" when called inside let context. > > >> And the patch makes `case-fold-search' buffer-local internally. Nothing > >> needs to call (make-variable-buffer-local 'case-fold-search). > > > > The patch itself calls make-variable-buffer-local. > > On top level, when Emacs defines all other variables. So, my call to > make-variable-buffer-local is not inside let and thus should not have > any problem with the paragraph you quoted. I think this is a misunderstanding: the quote from the ELisp manual doesn't describe the situation where make-variable-buffer-local is called inside a let-binding. It is describing the behavior of 'let' when the variable was made buffer-local via make-variable-buffer-local.