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

From: Eli Zaretskii <[email-masked]>
Date: Mon, 10 Mar 2025 18:05:38 +0200

> Date: Sun, 9 Mar 2025 23:33:03 -0700
> Cc: [email-masked]
> From: Paul Eggert <[email-masked]>
> 
> On 2025-03-09 21:18, Richard Stallman wrote:
> > The idea was that a user could give the program any name,
> > and it would still behave the same.
> 
> Yes, the idea is that a user can copy /usr/bin/ctags to (for example) 
> /usr/bin/ceetags or /home/eggert/bin/sitags and the command will still 
> work under its new name.

If we must support arbitrary renames of programs that are not
synchronized across the entire Emacs installation, i.e. not bounded by
what we have in --program-transform-name=PROGRAM and --program-prefix
etc., then no wrapper script can ever work reliably to cause etags
work as ctags, because the script will be unable to find the correct
etags to run.

> If ctags invokes etags by replacing $0's basename with "etags", copying 
> /usr/bin/ctags to /usr/bin/ceetags just works, whereas copying 
> /usr/bin/ctags to /home/eggert/bin/sitags will require that the user 
> also copy or link /usr/bin/etags to /home/eggert/bin/etags. I assume 
> this requirement is OK (as I understand it, Eli says it's OK).

This requirement will be OK if the programs were renamed using the
facilities mentioned above, or at least the most common uses fog them.

> Dropping support for ctags output would address the problem by removing 
> the need for two programs. And since there is a GPL'ed ctags[1] that is 
> better than what's shipped with Emacs, one option is for Emacs to stop 
> installing ctags, and to advise users who want a ctags program to use 
> the other ctags instead. That's the default on many distros nowadays anyway.

We can do something less drastic: tell them to use "etags --ctags"
instead.

> More radically, Emacs could also stop installing etags, and advise 
> people to run ctags -e instead, where this is the other ctags.

To this I object, since the master source of the format of the TAGS
files must be in Emacs, and what better to document this format than
to maintain and distribute etags the program.

> As a practical matter, ctags and etags both have problems with languages 
> like C++ and Python where the same name can mean many different things 
> depending on context. My impression is that nowadays many (most?) people 
> who want tags-like capabilities use Language Server Protocol[2] clients 
> like lsp-mode[3] instead, as LSP can handle these more-complicated 
> naming conventions. Ctags and etags are mostly needed for old-fashioned 
> users.

Given that there still is no GCC-based LSP server for C and C++, using
LSP for C/C++ development means one needs to install clang in addition
to GCC, and that is a nuisance.

(I urged the GCC developers several years ago to develop LSP
capabilities, but AFAIK nothing practical came out if that.)

In any case, etags is a much more lightweight solution for what it
provides (which us only a small part of what an LSP server can
provide), so removing it for that reason would be unwise, IMO.