Re: etags name collision.

[Ergus <spacibba@aol.com>]

Hi Eli:

On Mon, Apr 11, 2022 at 04:18:43PM +0300, Eli Zaretskii wrote:
>> Date: Mon, 11 Apr 2022 14:47:36 +0200
>> From: Ergus <spacibba@aol.com>
>>
>> 1) Why do we have etags+ctags executables so far they do more or less
>> the same work right?.
>
>Because ctags produces tags table in a format understood by more
>applications than just Emacs.
>
>> 2) Why do we create an executable with a name that is used by another
>> very wheel known program.
>
>It's the other way around: ctags was a very old Unix program, and
>Emacs developed a GNU version of that program.  Universal ctags came
>much later.  So you should ask them why did they decide to use a name
>that was already taken.
>
For whatever reason their version is much better, maintained and with
more active development, support and people. It's free in all the senses
and provided in some GNU/Linux distros by default or available in 100%
of the repositories... so don't fight them, join then that did a good
work stablishing as the standard. (Do one thing and do it right)

>> 3) Could we consider to keep only etags and remove the ctags file in
>> order to let the users to access.
>
>I don't see why we should remove a program just because someone who
>uses an incompatible program by the same name should manage his/her
>installations.  A simple solution is for that user to not install the
>Emacs version of ctags.
>
There is no consistent way to do that in many distros they don't have
emacs users so they declare emacs incompatible with ctags and the user
needs to choose.

There is not even an option to disable the creation of ctags during
emacs configure/build; so it needs to be removed every time.

>> In general when the users want to use ctags I am pretty sure they refer
>> to universal or exuberant ctags today... But also such executable create
>> inconsistencies when using TRAMP and the support for languages like Rust
>> or modern C++ is not good; so maybe an even more radical approach may be
>> considered. Some distros like Arch Linux explicitly rename it to solve
>> the conflict, but if we have etags already, do we really need the other
>> executable?
>
>Emacs doesn't need ctags

So we shouldn't provide ctags by default. It is like if the Linux kernel
provide git and bash because they are useful. We don't have man power to
maintain it and support all the languages and features Exhuberant or
Universal do. But also in many distros ctags is actually provided by
default.

>but users might need it for working with
>other development tools.
>
The users who use ctags they only know about the other versions like
universal or exuberant; most of them don't even know that emacs provides
a ctags version and it only causes troubles.

At least could we condition the creation of ctags with a build/configure
option??
  Best,
Ergus