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

Previous Next

Full log

Message #289 received at 66117 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: dmitry <at> gutov.dev, yantar92 <at> posteo.net, mattias.engdegard <at> gmail.com,
 66117 <at> debbugs.gnu.org
Subject: Re: bug#66117: 30.0.50; `find-buffer-visiting' is slow when opening
 large number of buffers
Date: Thu, 14 Dec 2023 15:57:08 -0500

> Maybe.  This discussion has enough confusion to confuse everyone.

I've already been fooled more than once in this thread, indeed :-)

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

Oh, no, I'm definitely not sure, but since fixing this problem was cited
as part of the motivation for the introduction of
`case-fold-search-override`, I hope we have at least one or two concrete
cases showing that it's a real problem.

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

Really?  There are many let-bindings of `case-fold-search` in the tree,
so it's hard to get a clear picture, but a random sampling of them
suggests they mostly wrap searches where the regexps are not provided by
the user but by the wrapped code (they're typically hard-coded).

Admittedly, that doesn't mean that it would be wrong to obey the user's choice
of `case-fold-search` there, but I think it clearly leans this way.

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

But I was talking about code which performs a search that's internal to
the command rather than being the purpose of the command.  Things like
searches performed during indentation, searches performed to parse
the output of processes, ...

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

We do use it for 2 different purposes, indeed.
And I have seen this lead to bugs.

But the bugs I recall went in the direction "user setting unexpectedly
affecting internal searches" rather than "let-binding unexpected
affecting user searches".

I must admit that I can't point to concrete examples of the kind of bugs
"I recall".  But I don't know of examples of bugs caused by let-bindings
overriding user settings either.
So all in all, this seems like a weak justification for any change.


        Stefan

Previous Next

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