emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags


From: Francesco Potorti`
Subject: Re: [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags`
Date: Sat, 30 Dec 2006 13:15:55 +0100

>    This also happens with the Emacs 21 version of etags.  Olaf Dabrunz once
>    suggested that ctags optionally allows for duplicate entries, which
>    modern versions of vi can handle.
>
>Could you explain more clearly what this change means?
>What does it mean to have "duplicate entries", and what would they do?

Inside a tags file as generated by Emacs' Ctags, tag names are unique.
For example, Linux defines macros with the same name in different source
files, with alternative implementations.  While Etags tags them all,
Ctags does not.  There is nothing preventing Ctags from doing that, it
simply refuses to do it.

In a year-old mail, Olaf Dabrunz suggested to me that this behaviour of
Ctags, which I inherited, is there for compatibility with old editors,
like the original Vi, while Vim can take advantage of duplicate entries.
He then suggested that Ctags optionally allows for duplicate tags, which
is a trivial change.

Now I am asking: is there really any reason why Ctags should not create
duplicate entries?  Why not creating duplicate entries by default?  The
only drawback would be that the old Vi would jump to an unpredictable
one, but the current behaviour is not much better, because only the
first duplicate tag is created, the others are not included in the tags
file.

Olaf Dabrunz cites this proposed standard, used by at least Exhuberant
ctags and Vim: <http://ctags.sourceforge.net/FORMAT>, where the issue is
better explained.

In summary, I have three proposals for a change to Ctags, preferred first:

1. Duplicate entries are created, no warnings issued
2. Duplicate entries are created, warnings issued as they are now
3. An option is provided to create duplicate entries

If a consensus is reached quickly, I can do the change now, during the
pretest phase.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]