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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: yantar92@posteo.net,  dmitry@gutov.dev,  66117@debbugs.gnu.org,
>   mattias.engdegard@gmail.com
> Date: Thu, 14 Dec 2023 14:49:54 -0500
> 
> >> 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`).

Maybe.  This discussion has enough confusion to confuse everyone.

> >> > 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.

Not all, just some.

> 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.

Yes, and you are sure there aren't such cases, what with our
willy-nilly binding this variable whenever we need that?

> 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).

This is wishful thinking not based by any data.

> >> 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.

That's what I had in mind, and even said so.

> If the search is done within a non-search command (e.g. indentation),
> then the result is often not what the user wanted.

My point is that we use case-fold-search for two different purposes,
and so it is good to have 2 variables, one each for every purpose.