[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: auto-refresh TAGS file on ChangeLog mod?
From: |
Ted Zlatanov |
Subject: |
Re: auto-refresh TAGS file on ChangeLog mod? |
Date: |
Mon, 25 Aug 2008 09:45:36 -0500 |
User-agent: |
Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (gnu/linux) |
On Fri, 22 Aug 2008 09:43:14 -0600 Tom Tromey <address@hidden> 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
Message not available