[Top][All Lists]

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

Re: Generation of tags for the current project on the fly

From: Dmitry Gutov
Subject: Re: Generation of tags for the current project on the fly
Date: Thu, 18 Jan 2018 03:14:49 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Thunderbird/58.0

On 1/18/18 02:20, Tom Tromey wrote:

Dmitry> ctags supports incremental updates?

Yeah, see "-u" in "ctags --help":

Cool. This is probably from Universal Ctags. Still not in Ubuntu (17.04, at least).

-u, --update
         Update the tag entries for the given files, leaving tag
         entries for other files in place.  Currently, this is
         implemented by deleting the existing entries for the given
         files and then rewriting the new entries at the end of the
         tags file.  It is often faster to simply rebuild the entire
         tag file than to use this.

Seems like it updates the file in place. And your implementation copies the entries and allocates a new file. Any difference in performance that you noticed?

Dmitry> The config file duplicates some info in .gitignore and
Dmitry> project-vc-ignores, though. Which is unfortunate.

True, but there are two reasons for this.  One, there are still several
version control systems in use, and I didn't want to try to parse every
config file.

I think it should work like:

git ls-files | etags -

Replace 'git ls-files' with an appropriate incantation for each VCS.

Second, sometimes a generated file will be checked in, but
you might still want to omit it from TAGS -- so some mechanism like this
is needed.

Yup. This seems to work (excluding .clang_format; there's also an option to read additional ignores from a file):

git ls-files -cdmo --exclude-standard -x .clang-format | etags -

Dmitry> I also doubt that 'make tags' will go away anytime soon.

Sure, me too, but this approach is taken by more tools nowadays, and it
can live alongside "make tags".

Is that true? The modern tools have taken the approach of duplicating the ignore lists?

Dmitry> Any chance your code supports something analogous to 'global
Dmitry> --single-update' (except with multiple file arguments, hopefully)?
Dmitry> That's what I've been trying to describe.

It could certainly be done without much effort.

Very good. Does it handle file deletions as well?

I suppose I could push my branch to git if that would be convenient.
Just let me know.

Dmitry> I'm sure it would be helpful, even if only to study the approach.

I pushed it to feature/etags-update.

Thanks! I'll do some benchmarking if nobody beats me to it.

reply via email to

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