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

[Dmitry Gutov <dgutov@yandex.ru>]

On 2/8/18 00:30, Tom Tromey wrote:

> Dmitry> Maybe with a new option (e.g. 'etags -u --prune'), because it'll
> Dmitry> likely take some time. I wonder how much the overhead is going to be.
> 
> One idea would be to detect this situation at M-. time -- that is, when
> TAGS tells us about a file that doesn't exist, ignore the bad result and
> re-run etags --prune or whatever.

You mean call file-exists-p on all files in TAGS before each lookup? 
That would work. We also have the false positives returned from 
tags-completion-at-point-function to deal with.

I was thinking of using e.g. inotify when it's available, but have not 
decided on the fallbacks.

> The reason I added --find was to circumvent both this problem (though as
> you saw, I didn't actually write this part)

But which problem exactly? As we recall, 'etags --find' turned out to be 
somewhat slower than 'find ... | etags'.

> and also to deal with a
> couple other problems: the need to avoid Makefiles (gcc and gdb have to
> be built out-of-tree, which is a pain for running "make tags"), and
> consequently the need to have the config be accessible to etags itself.

I think, to a certain extent, we can get the same separation of 
information using the '--regex=@regexfile' and standardizing on a file 
name for that.

But this won't help recreate the multiple TAGS files structure with 
inclusions. As a smaller step forward, maybe 'make tags' will call 
'etags --prune' when a certain environment var is set.