emacs-devel
[Top][All Lists]
Advanced

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

Re: etags name collision.


From: Ergus
Subject: Re: etags name collision.
Date: Tue, 12 Apr 2022 18:40:16 +0200

On Tue, Apr 12, 2022 at 09:45:03AM -0400, Alfred M. Szmidt wrote:
  >Not all systems use Exuberant Ctags or Universal Ctags.  On the BSDs,
  >ctags is compatible with the Emacs ctags output (which is why it
  >exists, AFAIR).  Exuberant Ctags etc do not work with either vi(1) or
  >mg(1) on those systems, and their output is at odds with what is
  >standardized by POSIX.

  In what sense it is not standarized by POSIX?

The output from Exuberant ctags is not what POSIX asks for.  Programs
that expect the POSIX format will thus not work, or do funny stuff.

Again, I haven't observed that, that's exactly my point, if there is an
issue in universal ctags output format it should be reported, but I
haven't observed any mismatch.

  >So really, you're suggesting to remove a standardized utility and
  >replace it with non-standard ones that produce incompatible output
  >from what is generally accepted.

  I am suggesting to avoid the forced installation of a utility that we
  are not maintaining very well for another very well maintained, with
  more languages, support and formats.

That is changing the point I was making, that Emacs ctags produces the
standard ctags output where Exuberant ctags does not.

Universal ctags DOES generate standard ctags format (and some others
like etags format); they actually explicitly refer to vi in the man
page.

Exuberant is not maintained since 2011.

But, I do think that the Emacs maintainers will disagree that
ctags/etags is not being maintained.  Like everything in Emacs,
someone has to do the work,

and you're most welcome to send patches to
improve ctags (or etags).  We all would appreciate it.

If there is the free and active universal ctags with a big and active
team doing that work and supporting many format and languages, then it
is pointless to duplicate effort and invest time on that.  Don't
reinvent the wheel.


reply via email to

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