[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: Sun, 21 Jan 2018 15:26:27 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Thunderbird/58.0

On 1/21/18 2:57 AM, Tom Tromey wrote:
Dmitry> 3. 'lib-src/etags src/category.c -u -o TAGS' results in having only
Dmitry> that file's tags inside TAGS (before, it contained the entries for all
Dmitry> .c files). This behavior contradicts the help and stops the rest of my
Dmitry> testing in its tracks.

Another bug on my part, I think I've fixed it now.

Thanks! It's working better now, but here's another experiment:

~/v/emacs-master (feature/etags-update|…) $ make tags
<completes okay>
~/v/emacs-master (feature/etags-update|…) $ echo src/doc.c | lib-src/etags - -u -o src/TAGS ~/v/emacs-master (feature/etags-update|…) $ echo src/doc.c | lib-src/etags - -u -o src/TAGS
lib-src/etags: invalid TAGS file

Also getting the same result after a third call to 'etags --find'.

The next question for you is how you want it to work.

Right now there are two modes:

* The old mode (but with the possibility of -u)

That's how I'm going to use it for now. BTW, '--find' looks consistently slower here than 'find -name "*.rb" |':

$ bash -c "time find . -name \"*.rb\" | ~/vc/emacs-master/lib-src/etags - -o TAGS"

real    0m0,215s
user    0m0,200s
sys     0m0,116s
$ rm TAGS
$ bash -c "time ~/vc/emacs-master/lib-src/etags --find"

real    0m0,329s
user    0m0,180s
sys     0m0,136s
$ cat .etags

* --find mode -- which implies -u.  The .etags file is only read in find

Not sure --find should always imply -u, actually (or '-o TAGS'). Might be harder for debugging. Also, '--find' doesn't deal with deleted files, so you'll delete one, call '--find', and the entry will remain in TAGS.

Anyway, my intention for now is to cherry-pick the '-u' feature as soon as it's working well. Nothing against '--find', but it should probably be a separate discussion.

My idea for this code was to use locate-dominating-file to find the
.etags file and just run "etags --find" from there on save.

That would complicate things somewhat, especially when .etags is not a VC root of the project. You could create a .etags based project type, though.

However I know you'd like to use git ls-files, and maybe other things --
you mentioned correctly handling file deletions.

Speaking of deletions, this is not strictly necessary (we could just delete the whole TAGS and recreate), but it would be helpful if, when passed a non-existing file that is in TAGS, 'etags -u' deleted it from the index. Right now, it only complains "No such file or directory", but keeps it in the index.

reply via email to

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