From: Eli Zaretskii <eliz@gnu.org>
To: Dmitry Gutov <dgutov@yandex.ru>
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 15:02:20 +0300 [thread overview]
Message-ID: <8335putc4z.fsf@gnu.org> (raw)
In-Reply-To: <5679c01b-51d0-903d-039a-8102f64fdb37@yandex.ru> (message from Dmitry Gutov on Fri, 24 Sep 2021 14:40:51 +0300)
> Cc: mardani29@yahoo.es, 50733@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 24 Sep 2021 14:40:51 +0300
>
> > 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.
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.
> 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.
> > 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.
Hmm... I'm sure this worked in the past, at least for
xref-find-references? Or does that use a different variable?
> If you can suggest an
> appropriate invocation for xref-search-program-alist, I can try and add it.
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).
> But I thought id-tools are for scanning for identifiers, not for
> arbitrary regexp searches?
They can scan for identifiers that match regular expressions, where
"identifier" is defined by each file's PL.
> > 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.
Are you sure people indeed use project-find-regexp _only_ for
language-agnostic searches?
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.
next prev parent reply other threads:[~2021-09-24 12:02 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
2021-09-24 12:02 ` Eli Zaretskii [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8335putc4z.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=50733@debbugs.gnu.org \
--cc=dgutov@yandex.ru \
--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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.