From: Dmitry Gutov <dgutov@yandex.ru>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Generation of tags for the current project on the fly
Date: Mon, 15 Jan 2018 04:44:58 +0300 [thread overview]
Message-ID: <259c557d-e3a3-c01b-9ba3-30df09d247ea@yandex.ru> (raw)
In-Reply-To: <83y3l0za1f.fsf@gnu.org>
On 1/14/18 7:21 PM, Eli Zaretskii wrote:
>> OK, so if the user says yes, we "temporarily visit" to auto-generated
>> tags table. Then the user saves a file and that table get invalidated
>> (or via some other mechanism), and we want to index it again. Ask again?
>
> No, I think asking once per project should be enough.
Until the end of the current Emacs session? And ask again after restart?
What about if the user switches to a different project and then back?
> I mean the first time the tags table is required might very well be at
> the beginning of working on a project, at which time the project
> source tree is not yet in the cache.
Yes, and? The user will need it to be indexed either way, right?
There's also another optimization opportunity: performing reindexing in
an asynchronous fashion, in the background (maybe after a timeout, too),
after any file is changed and saved. This one comes with its own
tradeoffs, though.
>> For instance, could you try to see how long takes the generation of the
>> file list alone? And populating the buffer with it. But without passing
>> it to etags.
>
> What Lisp shall I use for that?
To measure the full time:
(benchmark 1 '(progn (etags--project-tags-cleanup)
(etags--maybe-use-project-tags)))
To measure the time to generate the list of files only:
(benchmark 1 '(all-completions "" (project-file-completion-table
(project-current) (list default-directory))))
>>> Invoking 'find' will always be faster, as it's optimized for
>>> traversing directory trees.
>>
>> 'git ls-files' will probably be faster still.
>
> Yes, but that only works in Git repositories.
We can probably optimize for that use case these days. Git or some other
VCS is usually in place, especially in non-toy projects.
>>> No, TAGS is a standard target in GNU Makefile's.
>>
>> OK, good to know. Two questions, then:
>>
>> - Can we make it output the tags to stdout?
>
> Not likely. But you could just visit the TAGS file(s), no?
Hmm, there are reasons not to do that in general, but if the way we
generate the files is known to be "right", they mostly disappear (except
for the implementation complexity: doing it this way and using temporary
files in the other case will require more code).
How do we figure which files to visit? Do we just visit src/TAGS and
expect the rest to be 'include'-d.
>> - Can we detect than a given Makefile has a proper TAGS target (that can
>> output to stdout)?
>
> Maybe CEDET has something, but if not, searching for ^TAGS: should be
> easy.
>
>> Not sure yet how to handle the TAGS files inclusions, though.
>
> "make TAGS" should handle it, as it does in Emacs.
So these questions have answers, good.
Here's another one: considering the reindexing costs are not always
negligible and depend on the size of a project, will there be actual
benefit to using the proposed scheme in GNU projects like Emacs, GCC and
others (those are the ones that use 'make TAGS')? Or is there a subset
of them, at least, which we expect to benefit?
next prev parent reply other threads:[~2018-01-15 1:44 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-12 1:02 Generation of tags for the current project on the fly Dmitry Gutov
2018-01-12 9:01 ` Eli Zaretskii
2018-01-12 13:52 ` Dmitry Gutov
2018-01-12 18:52 ` Eli Zaretskii
2018-01-14 2:05 ` Dmitry Gutov
2018-01-14 16:21 ` Eli Zaretskii
2018-01-15 1:44 ` Dmitry Gutov [this message]
2018-01-15 5:37 ` Eli Zaretskii
2018-01-15 18:50 ` Dmitry Gutov
2018-01-16 17:50 ` Eli Zaretskii
2018-01-16 21:56 ` Dmitry Gutov
2018-01-17 15:40 ` Eli Zaretskii
2018-01-17 19:43 ` Dmitry Gutov
2018-01-17 20:12 ` Eli Zaretskii
2018-01-17 22:19 ` Dmitry Gutov
2018-01-17 22:28 ` Dmitry Gutov
2018-01-17 22:02 ` Tom Tromey
2018-01-17 22:44 ` Dmitry Gutov
2018-01-17 23:20 ` Tom Tromey
2018-01-18 0:14 ` Dmitry Gutov
2018-01-18 1:30 ` Dmitry Gutov
2018-01-19 1:21 ` Dmitry Gutov
2018-01-20 22:15 ` Tom Tromey
2018-01-20 23:57 ` Tom Tromey
2018-01-21 12:26 ` Dmitry Gutov
2018-01-30 4:45 ` Tom Tromey
2018-02-04 23:32 ` Dmitry Gutov
2018-01-30 5:05 ` Tom Tromey
2018-02-04 23:40 ` Dmitry Gutov
2018-02-05 17:06 ` Eli Zaretskii
2018-02-05 20:10 ` Dmitry Gutov
2018-02-06 19:36 ` Eli Zaretskii
2018-02-06 20:41 ` Dmitry Gutov
2018-02-07 3:26 ` Eli Zaretskii
2018-02-07 9:47 ` Dmitry Gutov
2018-02-07 21:30 ` Tom Tromey
2018-02-09 9:41 ` Dmitry Gutov
2018-02-08 20:31 ` John Yates
2018-02-09 0:22 ` Dmitry Gutov
2020-12-08 22:26 ` Dmitry Gutov
2018-01-17 11:08 ` Dmitry Gutov
2018-01-15 1:50 ` John Yates
2018-01-15 5:42 ` Eli Zaretskii
2018-01-15 15:01 ` Dmitry Gutov
2018-01-15 17:21 ` Eli Zaretskii
2018-01-15 17:45 ` Dmitry Gutov
2018-01-15 20:56 ` Matthias Meulien
2018-01-15 21:44 ` Dmitry Gutov
2018-01-15 16:33 ` John Yates
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=259c557d-e3a3-c01b-9ba3-30df09d247ea@yandex.ru \
--to=dgutov@yandex.ru \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/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.