Re: auto-refresh TAGS file on ChangeLog mod?

From:

Ted Zlatanov

Subject:

Re: auto-refresh TAGS file on ChangeLog mod?

Date:

Fri, 22 Aug 2008 10:30:19 -0500

User-agent:

Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (gnu/linux)

On Thu, 21 Aug 2008 10:31:26 -0600 Tom Tromey <address@hidden> wrote:
Tom> I tried to solve this problem a couple times. Actually, I tried to
Tom> solve the more general problem of auto-updating TAGS in response to
Tom> any change, not just a change to some sentinel file.
Tom> Once I wrote a big patch to put the etags command-line arguments into
Tom> the TAGS file, so you could reliably re-run etags when a file was
Tom> saved. This never went in; in the end I think it is not the best
Tom> approach, since it doesn't handle changes occurring outside of Emacs,
Tom> and it doesn't have a way to handle new files.
Tom> My next approach was a "retags" script. This uses inotify to watch
Tom> for file changes, then re-runs etags. It uses a simple ".retags" file
Tom> to decide how to invoke etags -- this solves the "new file" problem.
Tom> I can send retags to you if you want. I posted it to emacs-sources
Tom> once. It is pretty slow, especially the first time it starts. That
Tom> is the main reason I don't use it.
Tom> I've wanted to roll the retags idea into etags itself. It could read
Tom> a ".retags" file, daemonize, and use inotify to watch for changes in a
Tom> directory tree. I never found the time to do it though.
I'd like the solution to be implemented in Emacs, not externally. Emacs
doesn't have inotify facilities AFAIK, but (like D-BUS) such system
support should be possible. The protocol, according to
http://lwn.net/Articles/142751/, is not too complicated. Is that a
possibility? If so, Emacs could watch for changes anywhere in the
directory where the TAGS file was found and, when changes occur, it
could redo the indexing. I'm sure other packages could use inotify
support as well.
Until inotify support, the list of files can be built when TAGS is
loaded (it has the file names), and then rescanned when needed. For
most cases that will perform OK.
New files of interest can probably be inferred by building a list of
extensions in TAGS; if you have .c files already then you'll want new.c
as well. I think anything more than this should require manual
reindexing or some user configuration of "I want to tag all *.c files."
Remembering the original list of files is not needed, right? Can you
just run "etags --append new_or_updated_files"? I think it's OK to have
outdated (deleted) entries in TAGS until a full rescan is done by the
user; I can't think of any other problems with this.
Ted