Re: Bug Report (Feature request?) etags (GNU Emacs 21.1)

[Sven Utcke]

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
| ' </ _ \/ _` (_-<  phone:    +49 (0)40 42883-2576      Vogt-Koelln-Strasse 30
|_|\_\___/\__, /__/  fax  :    +49 (0)40 42883-2572             D-22527 Hamburg
          |___/ http://kogs-www.informatik.uni-hamburg.de/~utcke/home.html