From mboxrd@z Thu Jan 1 00:00:00 1970 Path: quimby.gnus.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Bug Report (Feature request?) etags (GNU Emacs 21.1) Date: 21 Feb 2002 16:51:25 +0100 Message-ID: <5xvgcqrfya.fsf@kfs2.cua.dk> References: <200202211303.g1LD3ar29903@kogs46.informatik.uni-hamburg.de> NNTP-Posting-Host: quimby2.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: quimby2.netfonds.no 1014306760 15105 195.204.10.66 (21 Feb 2002 15:52:40 GMT) X-Complaints-To: usenet@quimby2.netfonds.no NNTP-Posting-Date: 21 Feb 2002 15:52:40 GMT Cc: Sven Utcke , Emacs developers Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby2.netfonds.no with esmtp (Exim 3.12 #1 (Debian)) id 16dvWS-0003vX-00 for ; Thu, 21 Feb 2002 16:52:40 +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 16dvVG-0002bX-00; Thu, 21 Feb 2002 10:51:26 -0500 Original-Received: from mail.filanet.dk ([195.215.206.179]) by fencepost.gnu.org with smtp (Exim 3.33 #1 (Debian)) id 16dvUA-0002ZM-00; Thu, 21 Feb 2002 10:50:18 -0500 Original-Received: from kfs2.cua.dk.cua.dk (kfs2.local.filanet.dk [192.168.1.182]) by mail.filanet.dk (Postfix) with SMTP id 443EA7C035; Thu, 21 Feb 2002 15:50:16 +0000 (GMT) Original-To: Francesco Potorti` In-Reply-To: Original-Lines: 89 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.50 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:1395 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:1395 Francesco Potorti` writes: > 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. I'm still not sure I understand all the implication of etags looking at #line lines. In the case of the C-preprocessor, there is a 1:1 correpondance between the line numbers in the source file and the target file, meaning that if it output a #line 1000 while at line 1000 (of course), then if you advance 25 lines in the target file, it corresponds to line 1025 of the source file (provided there are no other #line in those 25 lines). However, this will often NOT be the case when #line directives are found in files generated by other programs (there may be a 1:100 or a 100:1 correspondance) -- but you don't know. So etags will have to put the #line directive's line number directly into TAGS. So what are the implications of etags doing that? > 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. Suppose the source file is in written in YLAG which contains a the following declaration on line 100: FUNC f::x(a,b) { a /?/ b } The resulting myfile.c file will contain code corresponding to this looks something like this: #line "myfile.ylag" 100 _YLp * _YLfunc_x__f_(_YLp *a, _YLp *b) { return _YLop9(a,b); } So, what does etags put into the TAGS file about f::x ? It writes: _YLfunc_x__f_ is at line 100 in myfile.ylag Supposing that etags understood YLAG syntax, I would - as a user of etags - like to use M-. f::x RET to jump to the definition of f::x But I cannot do that, since etags according to your rule didn't parse myfile.ylag at all. Is that really acceptable? On the other hand, I can do M-. _YLfunc_x__f_ RET which (surprise) takes me to the declaration of f::x in myfile.ylag. That may be ok in some (most?) cases, but it may also be the wrong thing - if I was actually looking for that function trying to understand what is *really* going on at a low level. I don't know how to fix these problems (all solutions seem to counter-act each other). Here are some ideas: It has been mentioned before to put dual references into TAGS: one for the actual file, and one for the file from the #line directive. This is simple. Etags could somehow correlate the two files to see if they use "identical" identifiers, i.e. whether it really makes sense to not tag the source file. This seems non-trivial, as you really don't know what program was used to generate the target file -- even if those files are both, say, .c files, you really don't know if they share any identifiers (or other similarities). Eg. it could be that the generation of the target file specifically involved changing all identifiers. We could have a command which can go backwards in a file looking for a #line tag and jump to the referenced file and line (optionally plus the offset to that line). This would not really mess with (or even require) etags as all! Maybe such a function already exists? -- Kim F. Storm http://www.cua.dk _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel