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

[Kim F. Storm]

Francesco Potorti` <address@hidden> 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 <address@hidden> http://www.cua.dk