Re: etags name collision.

[Ergus <spacibba@aol.com>]

On Tue, Apr 12, 2022 at 01:21:53PM -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.
>
>I have observed the case, the POSIX format is stricter, the output
>from ctags as specified by POSIX is (there are slight variants, but it
>is always three fields):
>
>  "%s\t%s\t/%s/\n", <identifier>, <filename>, <pattern>
>
>for example, GNU Emacs ctags outputs:
>
>  syms_of_cmds	cmds.c	/^syms_of_cmds (void)$/
>
>where Exuberant (and Universal) ctags outputs:
>
>  syms_of_cmds	cmds.c	/^syms_of_cmds (void)$/;"	f	typeref:typename:void
>
Did you tried the format=1 option?

>It is fair to fail on not being able to accept the above, or treating
>the third field as one.  And one might also question how to treat a
>pattern with a trailing double quote.
>
>   >   >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.
>
>No, it does not.  See above; from Universal ctags from 2019.
>
See above

>   Exuberant is not maintained since 2011.
>
>People still use software that is older, just that something is "not
>maintained" (which can mean many things) doesn't mean that it stops
>being useless.
>
Agree, but any error in Exuberant Ctags has been fixed in Universal
version and can be reported there to be fixed immediately.

>   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.
>
>That is quite a dismissive comment, Emacs ctags existed long before
>any of those existed (and at that point, we did not have any ctags on
>GNU) so one might question who is reinventing the wheel here...
>
Agree, but now their wheel is better. If they had the motivation, man
power and patience to implement something more complete and compatible,
in a shorter time and share it with the community for 10 years, the fact
that many users prefer it and the backward compatibility they have with
the original version... plus a lack of man power we have...  it is
pointless to duplicate the effort. Emacs developers should join effort
in other direction (treesitter, lsp, project features and so on; that's
my personal opinion of course.)