all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ergus <spacibba@aol.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: etags name collision.
Date: Mon, 11 Apr 2022 15:47:49 +0200	[thread overview]
Message-ID: <20220411134749.ps6g5ulpbamzm6ot@Ergus> (raw)
In-Reply-To: <83pmln69n0.fsf@gnu.org>

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



  parent reply	other threads:[~2022-04-11 13:47 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20220411124736.3qijvtearh6wlen7.ref@Ergus>
2022-04-11 12:47 ` etags name collision Ergus
2022-04-11 13:18   ` Eli Zaretskii
2022-04-11 13:38     ` Dmitry Gutov
2022-04-11 13:52       ` Ergus
2022-04-11 14:11         ` Eli Zaretskii
2022-04-11 14:25           ` Ergus
2022-04-12  7:16             ` Alfred M. Szmidt
2022-04-12  8:30               ` Andreas Schwab
2022-04-12 10:48               ` Ergus
2022-04-12 10:51                 ` Po Lu
2022-04-12 11:03                   ` Ergus
2022-04-12 11:13                   ` Dmitry Gutov
2022-04-12 11:28                     ` Po Lu
2022-04-12 13:45                       ` Alfred M. Szmidt
2022-04-12 14:29                         ` Dmitry Gutov
2022-04-12 15:36                           ` Óscar Fuentes
2022-04-12 17:13                           ` Ergus
2022-04-12 13:45                   ` Alfred M. Szmidt
2022-04-12 13:45                 ` Alfred M. Szmidt
2022-04-12 16:40                   ` Ergus
2022-04-12 17:21                     ` Alfred M. Szmidt
2022-04-12 17:48                       ` Ergus
2022-04-12 19:50                         ` Alfred M. Szmidt
2022-04-12 20:49                           ` Dmitry Gutov
2022-04-13  5:45                             ` Alfred M. Szmidt
2022-04-12 17:53                       ` Stefan Monnier
2022-04-11 13:59       ` Andreas Schwab
2022-04-11 14:07       ` Eli Zaretskii
2022-04-11 13:47     ` Ergus [this message]
2022-04-11 14:09       ` Eli Zaretskii
2022-04-11 14:18         ` Ergus
2022-04-11 15:46         ` [PATCH] " Ergus
2022-04-11 15:51           ` Eli Zaretskii
2022-04-11 16:19             ` Ergus
2022-04-11 16:40               ` Eli Zaretskii
2022-04-11 19:19                 ` Ergus
2022-04-11 19:39                   ` Ulrich Mueller
2022-04-11 19:53                     ` Ergus
2022-04-11 21:04                       ` Ulrich Mueller
2022-04-11 22:20                         ` Ergus
2022-04-12  7:21                           ` Alfred M. Szmidt
2022-04-12  7:34                             ` Ulrich Mueller
2022-04-12 10:53                             ` Ergus
2022-04-12  2:28                       ` Eli Zaretskii
2022-04-12  2:43                         ` Po Lu
2022-04-12  5:03                         ` Ulrich Mueller
2022-04-12 11:13                           ` Ergus
2022-04-12 11:48                             ` Eli Zaretskii
2022-04-12 11:56                               ` Eli Zaretskii
2022-04-12 12:50                             ` Ulrich Mueller
2022-04-12  7:16                         ` Alfred M. Szmidt
2022-04-12 12:15                   ` Eli Zaretskii
2022-04-11 16:46         ` Stefan Monnier
2022-04-11 17:01           ` Eli Zaretskii
2022-04-11 17:41             ` Stefan Monnier
2022-04-11 18:15               ` Eli Zaretskii
2022-04-11 19:11                 ` Ulrich Mueller
2022-04-12  7:42                 ` Thierry Volpiatto
2022-04-11 18:15               ` Ergus
2022-04-11 23:09               ` Ergus
2022-04-11 14:10     ` Andreas Schwab
2022-04-11 13:56   ` Kaushal Modi
2022-04-11 14:16     ` Óscar Fuentes
2022-04-12  3:19   ` Richard Stallman
2022-04-12  7:16     ` Alfred M. Szmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220411134749.ps6g5ulpbamzm6ot@Ergus \
    --to=spacibba@aol.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.