GNU bug report logs -
#66117
30.0.50; `find-buffer-visiting' is slow when opening large number of buffers
Previous Next
Reported by: Ihor Radchenko <yantar92 <at> posteo.net>
Date: Wed, 20 Sep 2023 08:53:02 UTC
Severity: minor
Found in version 30.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #205 received at 66117 <at> debbugs.gnu.org (full text, mbox):
On 13/12/2023 00:57, Stefan Monnier wrote:
>>> This said, in the case of `case-fold-search` I think there's a simpler
>>> solution: make it "buffer-local only", meaning that let-binding it
>>> affects only the current buffer (rather than affecting all the buffers
>>> which have not made it buffer-local yet).
>> Wouldn't that be a breaking change? And a non-obvious one.
> Yup.
>
>> E.g. company-dabbrev-code creates a dynamic binding for case-fold-search in
>> one place and then calls a function (company-dabbrev--search) that iterates
>> across all buffers with re-search-forward.
> I think we call this collateral damage.
>
> My suggestion was indeed not completely serious, tho I do think in the
> long run it's what we should do.
>
> BTW, regarding making BVAR slower, we could reduce its cost by
> introducing two versions of BVAR, so we only pay the price when
> accessing one of the problematic variables like `case-fold-search`.
Perhaps in the long run it might be good to do the opposite? Introduce
never-buffer-local variables, and make case-fold-search one of them.
I do see a few hits for
(setq-local case-fold-search
across the Emacs codebase, but in none of these I can clearly understand
the end goal (is that for interactive isearch?). Except for
ido-make-buffer-list-1, which is done purely for performance, working
around a problem related to what's being discussed here (df4991093b94).
This bug report was last modified 1 year and 136 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.