Subject: Re: bug#76322: Make ctags a thin wrapper around etags

From: Eli Zaretskii <[email-masked]>
Date: Thu, 13 Mar 2025 11:37:09 +0200

> From: Stefan Kangas <[email-masked]>
> Date: Wed, 12 Mar 2025 01:48:07 -0700
> Cc: [email-masked], [email-masked]
> 
> Paul Eggert <[email-masked]> writes:
> 
> > On 2025-03-11 21:26, Richard Stallman wrote:
> >> Can you summarize the important differences between this and our ctags?
> >> Can you summarize the important differences between this and etags?
> >
> > No. And as I haven't used ctags or etags (of any flavor) for decades, I
> > would not be a good choice to investigate details.
> 
> Two important differences:
> - Exuberant Ctags supports 160 languages, while our ctags supports 30.
> - Exuberant Ctags has much better support for new language features.

This sounds rather dismissive and lacking important details.

Our etags are a subprogram of Emacs, and thus need support mainly the
languages that Emacs supports.  How many of the languages for which
Emacs has a major mode are not supported by our etags?

As for support for "new language features", is that relevant for the
Emacs commands that use TAGS tables?  If so, can you tell the details?
which language features do we lack?

On the flip side, our etags seems to be about 10 times faster, at
least when running it on lib/, src/, and lisp/ directories of the
Emacs source tree (~1.5 sec vs ~16 sec on my system).

Anyway, not sure how this is relevant to the issue at hand.  I don't
think anyone is suggesting that we drop etags (and if someone does,
then I object), and whether we should drop ctags as a separate program
doesn't depend on how many languages it supports, because the main
arguments for dropping our ctags are that (a) Emacs doesn't use the
ctags format of the tags tables, and (b) that most distros package
Universal ctags as their preferred version.