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

[Dmitry Gutov]

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
!*
*.rb

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

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.