GNU bug report logs - #50733
28.0.1; project-find-regexp can block Emacs for a long time

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>, Gregory Heytings <gregory <at> heytings.org>
Cc: 50733 <at> debbugs.gnu.org, mardani29 <at> yahoo.es
Subject: bug#50733: 28.0.1; project-find-regexp can block Emacs for a long time
Date: Fri, 24 Sep 2021 18:50:20 +0300

On 24.09.2021 17:20, Eli Zaretskii wrote:

> More to the point: are you saying that a tool that returns more
> matches is necessarily better?  That'd fly in the face of our
> switching to the Xref package, whose explicit goal was to provide
> _fewer_ matches, the ones that matter.  Look closer at those matches
> which gid "missed", and you will see why it didn't show them to you.

Xref's find-definition and find-references indeed try to be more 
precise. But that's only for identifier searches.

> Oh, and if ripgrep finds only 45 matches, then something is wrong with
> it, because there are actually no less than 119 literal matches for
> O_CREAT in the tree (not counting many binary files that also match).
> So by this measure, ripgrep is also not the right tool for the job.

I'm guessing the remaining entries are somewhere in gitignore-d files?

>> Five seconds to scan the whole Emacs trunk is IMO not fast enough (ripgrep
>> does it in < 0.2 seconds).
> 
> Those 5 sec are invested only when needed, while the time it takes
> Grep/ripgrep to scan the files is invested every search.  Do this
> enough times, and you paid too much time.

FWIW, (project-find-regexp "O_CREAT") takes about 130ms here.

That's close to the perceptual "instant" time.

Previous Next

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