From: Francesco Potorti` <pot@gnu.org>
Cc: Emacs developers <emacs-devel@gnu.org>
Subject: Re: Bug Report (Feature request?) etags (GNU Emacs 21.1)
Date: Thu, 21 Feb 2002 15:43:34 +0100 [thread overview]
Message-ID: <E16duRa-0006Fb-00@pot.cnuce.cnr.it> (raw)
In-Reply-To: <200202211303.g1LD3ar29903@kogs46.informatik.uni-hamburg.de> (utcke@kogs1.informatik.uni-hamburg.de)
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.
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel
next parent reply other threads:[~2002-02-21 14:43 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200202211303.g1LD3ar29903@kogs46.informatik.uni-hamburg.de>
2002-02-21 14:43 ` Francesco Potorti` [this message]
2002-02-21 15:51 ` Bug Report (Feature request?) etags (GNU Emacs 21.1) Kim F. Storm
2002-02-21 16:21 ` Sven Utcke
2002-02-22 14:08 ` Francesco Potorti`
[not found] ` <200202220433.g1M4XAt14047@aztec.santafe.edu>
2002-02-22 11:48 ` Sven Utcke
2002-02-22 14:29 ` Francesco Potorti`
2002-02-22 14:56 ` Sven Utcke
2002-02-23 20:19 ` Richard Stallman
[not found] ` <200202220433.g1M4X3f14032@aztec.santafe.edu>
2002-02-22 14:10 ` Francesco Potorti`
2002-02-22 15:02 ` Sven Utcke
2002-02-22 16:27 ` Stefan Monnier
[not found] <200202220433.g1M4XCj14050@aztec.santafe.edu>
2002-02-22 11:37 ` Sven Utcke
2002-02-23 20:19 ` Richard Stallman
[not found] <200202141816.g1EIGWQ19766@kogs12.informatik.uni-hamburg.de>
[not found] ` <871yfjhgk7.fsf@pot.cnuce.cnr.it>
[not found] ` <5xg03zg0hc.fsf@kfs2.cua.dk>
[not found] ` <vd0bsenf432.fsf@kogs12.informatik.uni-hamburg.de>
[not found] ` <5xu1sfq8t9.fsf@kfs2.cua.dk>
[not found] ` <Pine.SUN.3.91.1020218153612.5449D-100000@is>
[not found] ` <87n0y6emxz.fsf@pot.cnuce.cnr.it>
[not found] ` <uofimd4mp.fsf@synopsys.com>
[not found] ` <87lmdq7cwm.fsf@creche.redhat.com>
[not found] ` <87eljie7ty.fsf@pot.cnuce.cnr.it>
[not found] ` <200202192131.g1JLVp413268@aztec.santafe.edu>
2002-03-05 12:15 ` Francesco Potorti`
2002-03-05 13:11 ` Sven Utcke
2002-03-06 5:57 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E16duRa-0006Fb-00@pot.cnuce.cnr.it \
--to=pot@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.