[Top][All Lists]
[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.
- Re: Bug Report (Feature request?) etags (GNU Emacs 21.1),
Francesco Potorti` <=