GNU bug report logs - #66117
30.0.50; `find-buffer-visiting' is slow when opening large number of buffers

Previous Next

Full log

View this message in rfc822 format

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: dmitry <at> gutov.dev, Eli Zaretskii <eliz <at> gnu.org>, mattias.engdegard <at> gmail.com, 66117 <at> debbugs.gnu.org
Subject: bug#66117: 30.0.50; `find-buffer-visiting' is slow when opening large number of buffers
Date: Fri, 15 Dec 2023 10:19:29 +0000

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> In my mind, another benefit is that the new variable will not be
>> affected by buffer-local values - (let (case-fold-search-override value) ...)
>> will be guaranteed to use VALUE everywhere, even if current buffer is
>> changed. This will make the case I described in
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66117#208 more predictable
>> (and, since it is a new variable, will not break any existing code).
>
> But of course, as always it cuts both ways.  E.g. if you do
>
>     (let ((case-fold-search-override t))
>       (dolist (buf (buffer-list))
>         (when (string-match "foo" buffer-file-name)
>           (do-something))))
>
> your `case-fold-search-override` will override all the careful
> `case-fold-search` let-bindings used during the execution of `do-something`
> which will likely lead to new bugs.

Good point. I was hoping that together with this new variable we also
add a compiler warning encouraging to use the case-fold-search-override
_instead_ of case-fold-search everywhere. But I can indeed see how
people can get even more confused in such scenario.

Within the scope of this particular bug report, I am now leaning more
towards your idea with DEFVAR_LISP then.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Previous Next

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