bug#20629: 25.0.50; Regression: TAGS broken, can't find anything in C++ files.

["Francesco Potortì" <Potorti@isti.cnr.it>]

Eli Zaretskii:
>> From: Glenn Morris <rgm@gnu.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  20629@debbugs.gnu.org
>> Date: Fri, 29 May 2015 02:48:57 -0400
>> 
>> Dmitry Gutov wrote:
>> 
>> > If you want my opinion (please keep in mind: not an etags user),
>> > following in Exuberant Ctags's footsteps sounds best.
>> 
>> I'm not one either, but I've been meaning to ask: why is etags in Emacs?
>
>The answer to that is lost in history (for me).  Perhaps Richard and
>Francesco (cc'ed) will remember.

When Etags was written, the only alternative was the traditional Unix
Ctags, to which Etags was an improvement.  Since Etags is able to
produce traditional Ctags-style files, yuo can look at the macro CTAGS
in etags.c to spot the differences.  This is a historical summary:

 * 1983 Ctags originally by Ken Arnold.
 * 1984 Fortran added by Jim Kleckner.
 * 1984 Ed Pelegri-Llopart added C typedefs.
 * 1985 Emacs TAGS format by Richard Stallman.
 * 1989 Sam Kendall added C++.
 * 1992 Joseph B. Wells improved C and C++ parsing.
 * 1993 Francesco Potortì reorganized C and C++.
 * 1994 Line-by-line regexp tags by Tom Tromey.
 * 2001 Nested classes by Francesco Potortì (concept by Mykola Dzyuba).
 * 2002 #line directives by Francesco Potortì.

/* Define CTAGS to make the program "ctags" compatible with the usual one.
 Leave it undefined to make the program "etags", which makes emacs-style
 tag tables and tags typedefs, #defines and struct/union/enum by default. */

>But since it is here, it is, IMO, a Good Thing, because we can easily
>affect its operation where it's important to us.  Especially lately,
>when the front-end was changed, and the new one has different
>expectations.

Yes.  This is important.  Obviously, this could be done in any similar
program having an --emacs option (see for example ls --dired).

>> It's my (superficial) impression that etags hasn't progressed much since
>> then. The majority of the changes seem to have been generic code-cleanup
>> stuff.
>
>That's not true, there were a couple of non-trivial changes lately
>that are not cleanups, and I think there will be one more soon.  This
>thread discusses some of them, the other one is discussed here:
>
>  http://lists.gnu.org/archive/html/emacs-devel/2015-05/msg00291.html

There have been significant bug squashing, tagging improvements and
language supporting features added at least until 2004.  Very few after
that time from my part.

>> Is it that etags recognizes Emacs-specific C code that ctags does not?
>
>Which ctags do you allude to here?  There are quite a few of them out
>there.
>
>> My only motivation for asking is that it's good to reduce the number of
>> things that need to be maintained in Emacs, where possible.
>
>I don't think we should remove this one, no.

This is from an old mail, referring to around 2004:

>In fact, some years ago I run an in-depth comparison between etags and
>exhuberant ctags, with mixed results.  None excelled clearly with
>respect to the other.  Only two functionality I missed in etags: the
>ability to read directories (with optional recursion) and the ability to
>generate the new tags types introduced by ctags.

On the other hand, Ex-C is much more customisable on the command line
and has a much clearer code (even if I don't know whether this in fact
translates to easier code management).  At that time, I had even had an
email exchange with Ex-c authors to try and merge the code bases, but
this did not went on for lack of time.

So Etags was not bad at all some ten years ago.  I don't know if Ex-c or
others have significantly progressed in the meantime.