unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 50733@debbugs.gnu.org, mardani29@yahoo.es
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	[thread overview]
Message-ID: <5679c01b-51d0-903d-039a-8102f64fdb37@yandex.ru> (raw)
In-Reply-To: <83k0j6trau.fsf@gnu.org>

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.





  parent reply	other threads:[~2021-09-24 11:40 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <m1h7edq7sc.fsf.ref@yahoo.es>
2021-09-22  9:27 ` bug#50733: 28.0.1; project-find-regexp can block Emacs for a long time Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-22 19:09   ` Dmitry Gutov
2021-09-22 21:58     ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-22 23:09       ` Dmitry Gutov
2021-09-23 17:41         ` Dmitry Gutov
2021-09-23 21:17         ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-23 22:40           ` Dmitry Gutov
2021-09-24  6:34             ` Eli Zaretskii
2021-09-24  7:02               ` Juri Linkov
2021-09-24 10:43                 ` Eli Zaretskii
2021-09-24 15:30                   ` Juri Linkov
2021-09-24 16:08                     ` Eli Zaretskii
2021-09-24  9:00               ` Gregory Heytings
2021-09-24 11:00                 ` Eli Zaretskii
2021-09-24 11:43                   ` Dmitry Gutov
2021-09-24 13:18                   ` Gregory Heytings
2021-09-24 14:20                     ` Eli Zaretskii
2021-09-24 15:50                       ` Dmitry Gutov
2021-09-24 16:18                         ` Eli Zaretskii
2021-09-24 16:22                           ` Dmitry Gutov
2021-09-24 16:24                       ` Gregory Heytings
2021-09-24 17:49                         ` Eli Zaretskii
2021-09-24 17:52                           ` Gregory Heytings
2021-09-24 18:48                             ` Eli Zaretskii
2021-09-24 21:49                               ` Gregory Heytings
2021-09-25  6:26                                 ` Eli Zaretskii
2021-09-27  0:43                                   ` Gregory Heytings
2021-09-27  5:14                                     ` Eli Zaretskii
2021-09-27  9:23                                       ` Gregory Heytings
2021-09-27 11:48                                         ` Eli Zaretskii
2021-09-27 12:25                                           ` Gregory Heytings
2021-09-27 12:44                                             ` Eli Zaretskii
2021-09-27 19:36                                               ` Gregory Heytings
2021-09-28  5:17                                                 ` Eli Zaretskii
2021-09-28  8:23                                                   ` Gregory Heytings
2021-09-27 12:58                                             ` Dmitry Gutov
2021-09-27 13:05                                               ` Eli Zaretskii
2021-09-27 19:37                                                 ` Gregory Heytings
2021-09-24 18:17                           ` Dmitry Gutov
2021-09-24 18:51                             ` Eli Zaretskii
2021-09-24 11:40               ` Dmitry Gutov [this message]
2021-09-24 12:02                 ` Eli Zaretskii
2021-09-24 12:22                   ` Dmitry Gutov
2021-09-24 13:06                     ` Eli Zaretskii
2021-09-24 14:05                       ` Dmitry Gutov
2021-09-23  6:13       ` Eli Zaretskii
2021-09-23 20:42         ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-23 22:18           ` Dmitry Gutov
2021-09-24  6:03           ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5679c01b-51d0-903d-039a-8102f64fdb37@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=50733@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=mardani29@yahoo.es \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).