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

Previous Next

Full log

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

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

> From: Juri Linkov <juri <at> linkov.net>
> Cc: 78520 <at> debbugs.gnu.org,  spacibba <at> aol.com
> 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?

Previous Next

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