From mboxrd@z Thu Jan 1 00:00:00 1970 Path: quimby.gnus.org!not-for-mail From: Sven Utcke Newsgroups: gmane.emacs.devel Subject: Re: Bug Report (Feature request?) etags (GNU Emacs 21.1) Date: Thu, 21 Feb 2002 17:21:14 +0100 (CET) Message-ID: <200202211621.g1LGLEt01092@kogs46.informatik.uni-hamburg.de> NNTP-Posting-Host: quimby2.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: quimby2.netfonds.no 1014308721 16475 195.204.10.66 (21 Feb 2002 16:25:21 GMT) X-Complaints-To: usenet@quimby2.netfonds.no NNTP-Posting-Date: 21 Feb 2002 16:25:21 GMT Cc: pot@gnu.org (Francesco Potorti`), emacs-devel@gnu.org (Emacs developers) Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby2.netfonds.no with esmtp (Exim 3.12 #1 (Debian)) id 16dw25-0004Hd-00 for ; Thu, 21 Feb 2002 17:25:21 +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 16dw0y-0005Ep-00; Thu, 21 Feb 2002 11:24:12 -0500 Original-Received: from rzdspc1.informatik.uni-hamburg.de ([134.100.9.61]) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16dvyI-00054f-00; Thu, 21 Feb 2002 11:21:26 -0500 Original-Received: from kogs1.informatik.uni-hamburg.de (kogs1.informatik.uni-hamburg.de [134.100.12.111]) by rzdspc1.informatik.uni-hamburg.de (8.12.2/8.12.2) with ESMTP id g1LGLFt5023401; Thu, 21 Feb 2002 17:21:15 +0100 (CET) Original-Received: from kogs46.informatik.uni-hamburg.de (kogs46.informatik.uni-hamburg.de [134.100.12.146]) by kogs1.informatik.uni-hamburg.de (8.12.2/8.12.2) with ESMTP id g1LGLEWd018577; Thu, 21 Feb 2002 17:21:14 +0100 (CET) Original-Received: (from utcke@localhost) by kogs46.informatik.uni-hamburg.de (8.10.1/8.10.1) id g1LGLEt01092; Thu, 21 Feb 2002 17:21:14 +0100 (CET) Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: <5xvgcqrfya.fsf@kfs2.cua.dk> from "Kim F. Storm" at Feb 21, 2002 04:51:25 PM X-Mailer: ELM [version 2.5 PL2] X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) 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:1397 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:1397 Hello Kim, > 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). Yes. > 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. I do not think this is correct. The program generating the #line directives can, I think, be assumed to output a new #line directive whenever there is no 1:1 correspondence. So I don't think there should be a problem. This might look like this: --- snip --- /* 3: */ #line 210 "test-homology.web" int main(int argc,char**argv) { /* 6: */ #line 323 "test-homology.web" int c; extern char*optarg; char*bitangent_file= NULL; /* 8: */ #line 349 "test-homology.web" bitangent_array bitangents; /* 10: */ #line 113 "test-homology.web" outline_list_pointer outlines= NULL; outline_list_pointer the_outline= NULL; int num_outlines= 0; int i; --- snip --- Note that the line-number need not be monotonically increasing though (something the gdb handles badly, btw --- maybe I should post a bug-report :-) > 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? No. If etags understands YLAG, then it should preferably parse the original file, not the derived one. > 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? Sounds like a viable workaround, but I still believe that etags should honour #line directives (that's what they are there for, after all). Personally, I also believe that when both *.c and *.y were given to etags, it _should_ create dual references, both pointing to the *.y file... Sven -- _ __ The Cognitive Systems Group | |/ /___ __ _ ___ University of Hamburg | '