|
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.
[Prev in Thread] | Current Thread | [Next in Thread] |