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: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
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 16:06:16 +0300

> Cc: mardani29 <at> yahoo.es, 50733 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Fri, 24 Sep 2021 15:22:39 +0300
> 
> On 24.09.2021 15:02, Eli Zaretskii wrote:
> 
> > You don't need to convince me, I have all of those installed, and
> > couldn't do without them.  The difficulties are practical, not
> > principal.
> 
> Bundling extra tools affects the size of the distribution, for example. 
> I figured that's something you might have an opinion on.

I doubt that the size of the distribution matters much these days.
Especially since tools like Grep usually have very small sizes of the
binary distribution.

> >> What is the concern about the presence of the current maintainer? Would
> >> we do something different if he leaves? We'd probably need to find
> >> another maintainer, no?
> > 
> > Yes, and the question is: will we succeed, and how quickly?  We
> > already had a period of time without one, which means having no one is
> > not a theoretical danger.
> 
> I'm not sure how that affects our opinion on bundling, though.

It might mean that bundling won't happen for mundane reasons.

> > Just "gid -r <R>".  But if this could run in an arbitrary directory,
> > there should also be a "-f .../ID" argument, telling it where to find
> > the ID database (usually, in the project's root).
> 
> Anyway, it seems the most pressing problem is not the performance of the 
> external tool (ripgrep is quite fast, for example). But our 
> post-processing of the results, when there are a lot of them.

Yes.

> id-tools (or alternatives) could help avoid the "fetch all project 
> files" step, though. At the cost of extra manual management, which I 
> personally don't like much.

Why is that a problem?  We have midnight.el which could be part of the
solution.

> > Anyway, maybe we need a separate command, or a different (but similar)
> > tool, one that indexes the tokens in the project files instead of
> > scanning all of the files each time anew.
> 
> "Tokens" implies searching only for identifiers, no?

For ID Utils, yes (although in text files those are words).  For some
other similar tool it could be something else.

Previous Next

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