bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dmitry Gutov
Subject: bug#50733: 28.0.1; project-find-regexp can block Emacs for a long time
Date: Fri, 24 Sep 2021 14:40:51 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0

On 24.09.2021 09:34, Eli Zaretskii wrote:
Cc: 50733@debbugs.gnu.org
From: Dmitry Gutov <dgutov@yandex.ru>
Date: Fri, 24 Sep 2021 01:40:58 +0300

Perhaps on a platform like macOS we should consider bundling some
up-to-date search program, be it GNU Grep or Ripgrep.

Eli, have there ever been a similar proposal under discussion? IIRC
having to install external tools has been an issue on MS Windows as well
for a long time. We give recommendations, but Grep has never been
distributed together with Emacs. Any particular reason?

For comparison, VS Code bundles ripgrep. Or at least its macOS releases do.

Bundling an external program is problematic, but it can be done, of
course, provided that the license is right.  The problem is, we don't
provide macOS binaries, and we cannot rely on the fact that the
Windows binaries distribution will have its maintainer forever: we
already had periods of time without such a person.

If we just bundled GNU find and GNU grep in both distributions (or, for macOS, tell the distributors to do that), that would improve OOTB behavior for many users. It's not like there's a real chance that the user would prefer some different version of Grep, for example.

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?

We can recommend installing such tools, of course.

Maybe we could do better?

Btw, I don't understand why we focus on general-purpose text-searching
tools for these features.  Why not focus on packages like ID Utils
instead, they are so much faster.  Daniel, could you time the same
search in that large tree when xref-search-program is 'gid'?  (You'd
need to run 'mkid' first, to create the ID database, but that is
one-time, and is very fast.)

There is no such option in xref-search-program. If you can suggest an appropriate invocation for xref-search-program-alist, I can try and add it.

But I thought id-tools are for scanning for identifiers, not for arbitrary regexp searches?

>  As I told many times, I think this is
> the future: program language sensitive tools that use a precomputed
> DB.

xref-find-references implies some language-awareness. project-find-regexp does not.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]