[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: Fri, 9 Feb 2018 12:41:33 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Thunderbird/58.0

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 'address@hidden' 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.

reply via email to

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