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>

Full log


Message #42 received at control <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 3 days ago.

Previous Next


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