emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug Report (Feature request?) etags (GNU Emacs 21.1)


From: Francesco Potorti`
Subject: Re: Bug Report (Feature request?) etags (GNU Emacs 21.1)
Date: Thu, 21 Feb 2002 15:43:34 +0100

   Oh, ok.  For each file which you are going to generate there will be
   one chunk, possibly quite small, started by one or more of @o, @a or
   @c (other dialects will use other start-sequences).  This then
   references chunk-names [...]

I looked at http://w3.pppl.gov/%7ekrommes/fweb.html#SEC16, where named
modules are explained, and I was convinced that etags would need to
implement most of the functionality of a .web processor.

Does not make sense, given that we have the alternative of parsing the
generated files and generate tags that point to the .web file by having
etags look at #line directives.

So we must, in certain cases, parse #line directives.

Now we have these cases (jump to the conclusion if you do not care):

1) .web file and .c file
   In this case etags cannot parse the .web, but can parse the .c and
   make tags pointing to .web.  This is the most reasonable behaviour,
   and should ideally be the default one, or even the only possible one.

2) .y file alone
   Etags already handles this beacuse it can parse .y files.

3) .c file alone, generated by .y
   Etags should not honour #line, because we do not have a .y.  But is
   this case interesting?  Maybe not at all.  If people really need
   that, they can remove #line directives.  Or else etags could be
   instructed to behave like it does now, that is, by ignoring #line.

4) .c together with .y
   Currently Etags parses both, each on their own.  If we let etags by
   default (or always) honour #line, then we will have two sets of
   identical tags produced in the TAGS file.  We can live with this, or
   implement the logic that in this case, only one set should be
   produced.

5) .c together with .y on a TAGS file generated using etags --append
   In this case, to implement the logic that only one set should be
   produced, etags should read the TAGS file before appending to it.
   Easy. 


Conclusion:

1) etags will honour the #line directive by default

2) if problems will arise, there will be an option to disable this
   behaviour and use the current one instead, where #line is ignored

3) additionally, and as a separate improvement, when told to parse files
   X and Y, where Y contains #line directives pointing to X, do not tag
   X.  This allows to use `etags zz.y zz.c', and etags will only tag
   zz.c, and generate tags pointing to zz.y.  It will also be possible
   to use `etags xx.web xx.c' and etags will only tag xx.c with tags
   pointing to xx.web.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]