RE: IDE

[Drew Adams <drew.adams@oracle.com>]

> > (But I agree: the hard part is the parsing.  The TAGS file
> > data structure is not the problem.)
> 
> It *is* a problem as well. You basically have to re-generate the file
> each time you reparse the project (--append has its drawbacks), and GNU
> Global optimizes that (someone familiar with SQL databases should easily
> imagine a way to do that).
>
> Further, now we're forced to parse the TAGS file and perform filtering
> in Elisp, which can be performed faster in an external program. Global
> can help there as well (we don't really need FFI support, unless Global
> command line interface is found too limiting).

I'm not contrasting TAGS with Gnu Global.  You are free to do
that.  I am not arguing in favor of TAGS over other indexing
and querying mechanisms.

The TAGS file feature defines an index format and an index
query mechanism.  That's all.  How and when the content of a
given index gets generated or updated is a different question.

And that generation/updating involves parsing, which has
been acknowledged to be the hard part.

Everything you say in support of claiming that the data
structure "*is* a problem" is, in fact statements about
the problem of parsing, not the data structure format.

If you want to argue that any use of *files* to hold the
index structure is problematic then do so explicitly.

Even then, that does not invalidate the TAGS index
structure.  It need not be stored on disk, in principle.