From mboxrd@z Thu Jan 1 00:00:00 1970 Path: quimby.gnus.org!not-for-mail From: Francesco Potorti` Newsgroups: gmane.emacs.devel Subject: Re: Bug Report (Feature request?) etags (GNU Emacs 21.1) Date: Thu, 21 Feb 2002 15:43:34 +0100 Organization: X-fingerprint: 4B2 6187 5C3 D6B1 2E31 7666 9DF 2DC9 BE21 6115 Message-ID: References: <200202211303.g1LD3ar29903@kogs46.informatik.uni-hamburg.de> NNTP-Posting-Host: quimby2.netfonds.no X-Trace: quimby2.netfonds.no 1014302787 12023 195.204.10.66 (21 Feb 2002 14:46:27 GMT) X-Complaints-To: usenet@quimby2.netfonds.no NNTP-Posting-Date: 21 Feb 2002 14:46:27 GMT Cc: Emacs developers Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby2.netfonds.no with esmtp (Exim 3.12 #1 (Debian)) id 16duUN-00037p-00 for ; Thu, 21 Feb 2002 15:46:27 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16duTG-0005b1-00; Thu, 21 Feb 2002 09:45:18 -0500 Original-Received: from pot.cnuce.cnr.it ([146.48.83.182]) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16duRh-0005KX-00 for ; Thu, 21 Feb 2002 09:43:42 -0500 Original-Received: from pot by pot.cnuce.cnr.it with local (Exim 3.34 #1 (Debian)) id 16duRa-0006Fb-00; Thu, 21 Feb 2002 15:43:34 +0100 Original-To: Sven Utcke In-reply-to: <200202211303.g1LD3ar29903@kogs46.informatik.uni-hamburg.de> (utcke@kogs1.informatik.uni-hamburg.de) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: quimby.gnus.org gmane.emacs.devel:1394 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:1394 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