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

Previous Next

Package: emacs;

Reported by: Ergus <spacibba <at> aol.com>

Date: Tue, 20 May 2025 23:34:02 UTC

Severity: normal

Tags: fixed

Found in version 31.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: spacibba <at> aol.com, 78520 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#78520: 31.0.50; Performance issue in dired+isearch with
 dired-isearch-filenames
Date: Sat, 24 May 2025 10:56:13 +0300
tags 78520 wontfix
close 78520
thanks

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: Juri Linkov <juri <at> linkov.net>,  spacibba <at> aol.com,  78520 <at> debbugs.gnu.org
> Date: Fri, 23 May 2025 23:09:25 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > > 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?
> 
> IIRC (and understand correctly): It had been tried and was faster, but:
> we then had dismissed this idea.  One reason was that we wanted to make
> ^ and $ match the beginning and end of the file names when using regexp
> file name isearch.  There were other reasons - lazy highlight, I don't
> recall.  There were a few problems, you find it somewhere.  The decision
> was not taken lightly - the result was just not convincing, and the
> problems not fixable in a sensible way.

Thanks.  I guess this means users of this feature will have to live
with the slowdown.

I'm therefore closing this bug.




This bug report was last modified 21 days ago.

Previous Next


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