Subject: Re: bug#78520: 31.0.50; Performance issue in dired+isearch with dired-isearch-filenames

From: Eli Zaretskii <[email-masked]>
Date: Fri, 23 May 2025 10:08:33 +0300

> From: Juri Linkov <[email-masked]>
> Cc: [email-masked],  [email-masked]
> Date: Thu, 22 May 2025 19:58:07 +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?