From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#66117: 30.0.50; `find-buffer-visiting' is slow when opening large number of buffers Date: Thu, 14 Dec 2023 14:49:54 -0500 Message-ID: References: <878r919qfh.fsf@localhost> <87plzbxtxa.fsf@localhost> <87y1dzvvf0.fsf@localhost> <83plzas3pg.fsf@gnu.org> <87r0jqw8u9.fsf@localhost> <83jzpis08a.fsf@gnu.org> <87il52w744.fsf@localhost> <83fs06rz10.fsf@gnu.org> <87fs06w4ui.fsf@localhost> <83bkaurut9.fsf@gnu.org> <87o7esq319.fsf@localhost> <83bkasrb3f.fsf@gnu.org> <83wmtgpuyf.fsf@gnu.org> <83r0jopqk1.fsf@gnu.org> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7501"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: dmitry@gutov.dev, yantar92@posteo.net, mattias.engdegard@gmail.com, 66117@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 14 20:51:22 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 1rDrju-0001ht-9d for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 14 Dec 2023 20:51:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rDrjb-0003Dh-8k; Thu, 14 Dec 2023 14:51:03 -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 1rDrja-0003DY-Do for bug-gnu-emacs@gnu.org; Thu, 14 Dec 2023 14:51:02 -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 1rDrja-0005YB-65 for bug-gnu-emacs@gnu.org; Thu, 14 Dec 2023 14:51:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rDrjZ-0006h7-I9 for bug-gnu-emacs@gnu.org; Thu, 14 Dec 2023 14:51:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Dec 2023 19:51:01 +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.170258340425628 (code B ref 66117); Thu, 14 Dec 2023 19:51:01 +0000 Original-Received: (at 66117) by debbugs.gnu.org; 14 Dec 2023 19:50:04 +0000 Original-Received: from localhost ([127.0.0.1]:50967 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rDrid-0006fG-RU for submit@debbugs.gnu.org; Thu, 14 Dec 2023 14:50:04 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:31862) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rDric-0006eZ-Fs for 66117@debbugs.gnu.org; Thu, 14 Dec 2023 14:50:03 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 72C8D4419C3; Thu, 14 Dec 2023 14:49:57 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1702583395; bh=8tzD1jfkQ0/iHCv6ygpVrGpK4/Hvl6il84hJtqc1v5U=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=f/fuP/dgz3oN8a8LXBRYSyASATPzHKX0Y0VdZJGyXXvu8EvY4OwGLtg11Gnw/Pyip eVyexjKLeOKqKM+ZO2+8oW+5JezeXGWfFUIPsvtqnbuOpUsQMoZWXp9A9YrrSfdqKB mIdoiQ7EiWwAvoi2rj0MVT5TyVyxS01C6ob2BLyYMokDNRl367v/zKELh0r5c3LxgC zMjOPDXGD63Ie4c4yaMw21D5mJNQaod7RTqZx4lg8k9d1CsftnF0Eij9riu00DI6ui GGW/4zs2wFH1M4czEarcsM/YYNma4BkokdQFTTnKBUkCy5cROjRjm2SxkRBPLlzes4 E59Qjt52YhhgQ== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id CB06B4418ED; Thu, 14 Dec 2023 14:49:55 -0500 (EST) Original-Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 96B0C120C16; Thu, 14 Dec 2023 14:49:55 -0500 (EST) In-Reply-To: <83r0jopqk1.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 14 Dec 2023 20:49:50 +0200") 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:276215 Archived-At: >> >> > But for starters, a new Lisp-only global variable should be good, I >> >> > think. Stefan, any comments? >> >> >> >> I must say I don't understand the reasoning behind this. >> >> What would it do different from `case-fold-search`? >> > >> > It won't be buffer-local-if-changed, so binding it will not be costly. >> >> As mentioned elsewhere in this bug-report we can make `case-fold-search` >> into a `DEFVAR_LISP`: it would have no visible impact to ELisp and would >> avoid the costly let-bindings. > Didn't we just agree that would be a breaking change? No, when? where? You might be confusing that proposition to my proposition to make it always-buffer-local (like `mode-name` or `buffer-file-name`). >> > It also won't be a defcustom, so let-binding it will not step on the >> > user's preferences. >> Hmm... when/where do existing let-bindings of `case-fold-search` step on >> user settings of that var? > Each time we let-bind it in code used in searching and/or matching > commands. I don't think that true of all those let-binding. Obviously the mere fact that the let-binding takes precedence means that we override the user's setting, but that's just an internal technical detail. To "step on the user's preference" we additionally need a situation where the user-visible result is not what the user wanted. Which of those let-binding can really be said to "step on the user's preference"? AFAICT most/all the times we do that, it's because we do a search that's "internal" to some operation and has thus no reason to obey the custom setting ,which AFAICT is meant to affect interactive uses like Isearch (tho Isearch doesn't Isearch doesn't pay attention to `case-fold-search`, AFAICT, so really the user-visible effect of setting `case-fold-search` is quite limited). I don't think that when users set `case-fold-search` to t they mean that indentation and highlighting should treat `STrucT` as a keyword in C mode, right? >> IME the problem is rather the opposite: most calls to search functions >> don't explicitly let-bind `case-fold-search` and instead rely naively on >> the default value and are thus susceptible to bugs if/when someone sets >> the custom var (globally or buffer-locally). > > I don't see that as a bug: the user said he/she wants the search to be > case-insensitive, so they should get what they asked for. But that's only true if the user runs a search command. If the search is done within a non-search command (e.g. indentation), then the result is often not what the user wanted. Stefan