Re: [Gnu-arch-users] Re: {arch} directory

[Robert Anderson]

On Fri, 2003-09-26 at 22:35, Dustin Sallings wrote:
> 
> On Friday, Sep 26, 2003, at 22:25 US/Pacific, Robert Anderson wrote:
> 
> >>    For example, I use ctags.  One of the projects I imported has a bunch
> >> of .c files in the top level directory, and a few in subdirectories.
> >> ``ctags -R .'' works fine in CVS.  I'm fine with modifying that to be
> >> ``ctags -R *'' since it's roughly about the same to type.  In order to
> >> do this with the {arch} directory, I need to do something like ``ctags
> >> -R [A-z0-9]*''  Or ``tla inventory --files | ctags -L -''
> >
> > Note that the presence of pristine trees is orthogonal to the name
> > "{arch}".
> 
>       Well, * matches {arch}, but does not match .arch, which is my point 
> here.
> 
> > That being said, what version of ctags are you referring to?  I'm 
> > pretty
> > sure it's not GNU ctags; your expressions don't "work" in any 
> > reasonable
> > sense, nor is there a "-L" option.  But I have a comment, depending on
> > what you're trying to do with those expressions.
> 
>       This is exuberant ctags 5.3 (see ctags.sf.net).  -R is recurse, and -L 
> is used to supply a list of source filenames.

Ok, so it's "recurse" and "list of files".

So, what does this version of ctags do about files of the form file.c~
in my tree (i.e. emacs autosave files)?  Does it tag those, or does it
have a built-in convention that it shouldn't?  What about things more
idiosyncratic to your tree that ctags doesn't have a built-in convention
for?  That what the --regex option is for, right?

There are lots of potential special cases of this form that you need to
work with not only ctags, but lots of auxilliary tools for working with
the sources in a tree.  But you pointed out a great example with ctags -
I use it too.

You see, one really nice thing about tla is that it centralizes all the
otherwise-crufty assumptions that tend to build up around scripts that
do things like feed files to ctags, by standardizing on a reasonable set
of logical file categories for source code trees: source, backups, and
junk are three examples.  I know that I always want to send the logical
set of files "source" to ctags.  I also know that what comprises
"source" in one tree is not necessary the same as another tree.  But if
I have a trivial, once-and-only-once script:

mktags:
#!/bin/sh
tla inventory --source | ctags -L -

I know that will work in all of my trees, and I won't have to go in and
tweak a list of regexps in a find . -name -prune expression every time I
switch trees.  It's automatically parameterized per tree, thanks to
tla's naming convention facilities.

So what I think you've pointed out is in fact one of the main reasons
why:

1) such namespace discipline is very powerful
2) given that, your complaints about the particulars of the {arch}
convention don't hold any water.

Yes, you should _do_ 'tla inventory --source | ctags -L', but for
goodness sake don't _type_ it.  'mktags' has sat well with me for about
the last decade.  Try it.

Bob