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

[Stefan Monnier]

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