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: Fri, 12 Jan 2018 16:52:21 +0300 [thread overview]
Message-ID: <b4d78c72-0153-52f9-54da-68bb5dda0713@yandex.ru> (raw)
In-Reply-To: <83shbb30z1.fsf@gnu.org>
On 1/12/18 12:01 PM, Eli Zaretskii wrote:
> Why discard it after the first save? The tags table is probably still
> very much valid.
Indeed, it's a rough heuristic. I'm aiming for correctness here, not for
performance.
On the other hand, code navigation and editing are often fairly distinct
activities, you don't switch between the two too frequently. So waiting
a second or two when going from the latter to the former shouldn't be
too terrible.
> I'd not discard it until either of the following
> happens:
>
> . we fail to find a tag
Not sure about this one. We can make this customizable, of course
(although the implementation might end up a bit convoluted), but IMO
it's not good for the default behavior.
Failing to find a tag is a valid result (some identifiers can be absent,
or defined somewhere else, e.g. in the libraries), and doing a rescan
each time that happens might be more annoying.
Further, some users will call C-u xref-find-definitions, look for the
new tag in the completion table, fail to find it there, and simply abort
without trying the search.
> . the user visits a tags table explicitly
That's of course, works already.
> . the user switches to a different project(?)
It's an omission currently, but yes, I fully intend to add this.
> We could offer generating a tags table if we don't find one in the
> tree, instead of generating it automatically.
And then what? Visit it? And make the user to rescan manually every
time? I'm fine with this as an optional behavior (and it will also be an
improvement, of course, since generating tags is not exactly trivial for
new users, and even many not-so-new ones), but I don't want this for the
default.
> I think this would be a
> better UI and UX, especially given the time it could take to generate
> TAGS (see below).
Sublime Text, Atom and VS Code simply index the project code, AFAIK,
without extra prompts. I think we should try to show a similar
experience, even if it's not great for big projects. There are several
directions we can improve on it, but showing the user that "yes, we can
find-definition right away" is a good thing.
>> For reference, indexing the Emacs sources takes ~1.1sec here.
>
> Was that with cold cache or warm cache?
Warm, probably. But that's the relevant time, isn't it? We're most
wondering how long it will take to *reindexing* (because we're
discussing when to do it). The first indexing will take place anyway.
> "make TAGS" takes about 9 sec here with a warm cache, and this is an
> SSD disk.
'make tags' makes 1 second on my machine, with an NVMe disk.
> On fencepost.gnu.org, a (somewhat slow) GNU/Linux system,
> it took 12 sec with a cold cache and 4 sec with a warm cache. And
> Emacs is not a large project; I wonder what would happen in larger
> ones, like GCC or glibc.
We can try to somehow detect very large projects, and helpfully offer to
visit a tags table instead. Anyway, M-x visit-tags-table still works.
> IOW, I don't think this is so fast that we could do that without user
> approval.
The argument here is that if the user called xref-find-definitions, it's
better to do a (long-ish) scan and show something, instead of failing.
They always have an option of C-g (we could also catch it and show
helpful instructions if the process took too long).
> I don't understand why you didn't use the commonly used form:
>
> find . -name "*.rb" -o -name "*.js" ... | etags -o- -
Because the project API doesn't make this easy. Anyway, generating the
full list of files is relatively fast in comparison. At most, it took
like 30% of the whole time (and less in other cases). And we can speed
it up further independently (e.g. using git ls-files).
> Doing things the way you did raises issues with encoding of file
> names, which could cause subtle problem in rare use cases.
Well, I haven't seen them yet, and don't really understand how they're
going to happen. But we'll probably fix them, one way or another.
> I think
> using 'find' is also faster.
find is used under the covers. The difference is just that the
invocations of etags are only happening later.
> More generally, I think doing this that way is not TRT, at least not
> by default. "make TAGS" in Emacs will produce a much richer tags
> table than your method, because our Makefiles use regexps to augment
> the automatic tagging in etags. So I think we should first try to
> invoke the TAGS target of a Makefile in the tree, if one exists, and
> only use the naïve command as fallback.
'make tags' is very much specific to Emacs. We can introduce some kind
of protocol, of course, but my primary goal here is to improve the
out-of-the-box behavior.
Further, the task will have to write tags to stdout: the current code
saves the temporary tags file to /tmp, and there are reasons to do that.
Anyway, that part shouldn't be too hard.
A possible venue for improvement is to somehow derive a multi-TAGS-files
structure (with their dependencies) from the project information. Still
thinking about it.
next prev parent reply other threads:[~2018-01-12 13:52 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 [this message]
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
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
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=b4d78c72-0153-52f9-54da-68bb5dda0713@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 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).