GNU bug report logs - #78520
31.0.50; Performance issue in dired+isearch with dired-isearch-filenames

Previous Next

Full log

View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: spacibba <at> aol.com, 78520 <at> debbugs.gnu.org
Subject: bug#78520: 31.0.50; Performance issue in dired+isearch with dired-isearch-filenames
Date: Fri, 23 May 2025 21:19:27 +0300

>> >> So unless someone wants to make an effort to optimize the
>> >> implementation more, IMHO this could be closed.
>> >
>> > Does isearch.el have some infrastructure for examining a match and
>> > rejecting it if it doesn't meet some criteria?  If so, can you point
>> > me to that infrastructure?
>> 
>> Everything is in 'search-within-boundaries' where 'next-fun'
>> is a lambda from 'isearch-search-fun-in-text-property'
>> that uses 'next-single-property-change'.
>
> Thanks, but what I meant was whether the "normal" search that searches
> the entire text has a facility to examine and reject potential
> matches.  isearch-search-fun-in-text-property looks only inside text
> that has a specified property, and that's not what I meant.  I meant
> this idea:
>
>> Would it be possible to speed this up by searching as usual, but then
>> rejecting matches whose positions don't have the 'filename' property?
>> Or was this tried and found to be not faster?
>
> Here, "searching as usual" means searching the entire buffer text, not
> just its chunks that have a specific property.
>
> Do we have such infrastructure in isearch.el?

To search the entire buffer text is possible by leaving uncustomized
the default value nil of 'dired-isearch-filenames'.

Or do you mean adding a new value to 'dired-isearch-filenames'
that will use 'isearch-filter-predicate' removed in the
commit 935cc4279568?

Then one value will use the current implementation
with 'isearch-search-fun-function'.  And a new value will use
the faster implementation with 'isearch-filter-predicate'.

But I have no idea how to explain this difference in documentation.

Previous Next

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