Re: auto-refresh TAGS file on ChangeLog mod?

[Ted Zlatanov <tzz@lifelogs.com>]

On Fri, 22 Aug 2008 09:43:14 -0600 Tom Tromey <tromey@redhat.com> wrote: 

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.

Ted> I'd like the solution to be implemented in Emacs, not externally.

Tom> Why is that?

I like to avoid external dependencies.

Tom> My first attempt was done that way.  But, given that etags is already
Tom> external to emacs, I reasoned that it doesn't buy much to go this
Tom> route.

I understand and see your side as well.  I was hoping to avoid another
external tool.  I'm not against it, just exploring the options.

Ted> Emacs doesn't have inotify facilities AFAIK

Tom> Nope.  FWIW, retags actually uses the inotify-tools package.  This is
Tom> just a couple of little inotify wrappers that are handy for shell
Tom> scripts; Emacs can use them just as easily.  But, as you say, adding
Tom> inotify support to Emacs would also not be difficult.

I don't know if asynchronous notices will be possible (I have to look at
the libraries), or if it should be implemented as a process filter to
inotify-tools.  The latter seems a much easier target.  I'm leaving this
despite (see below) thinking it's not necessary for retagging, because
inotify support for Emacs is probably going to be useful for other
packages.

Ted> New files of interest can probably be inferred by building a list of
Ted> extensions in TAGS; if you have .c files already then you'll want new.c
Ted> as well.  I think anything more than this should require manual
Ted> reindexing or some user configuration of "I want to tag all *.c files."

Tom> Right, this is where the .retags file comes in.  It tells retags what
Tom> to do.  The particular use case that I needed here was "don't index
Tom> anything in testsuite/".  I definitely do not want new .c files in
Tom> testsuite showing up...

Thanks for clarifying.  That's something I did not consider.  It's
probably easier to just have a Makefile that will track those
dependencies automatically.  Actually, what I think may be appropriate
is just a way to say "make tags" before running `find-tag'.  All the
extra intelligence is just duplicating what the user already has in the
Makefile, and what Make provides.  WDYT?

Ted