GNU bug report logs - #76322
Make ctags a thin wrapper around etags

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 76322 <at> debbugs.gnu.org, rms <at> gnu.org
Subject: bug#76322: Make ctags a thin wrapper around etags
Date: Mon, 10 Mar 2025 18:05:38 +0200

> Date: Sun, 9 Mar 2025 23:33:03 -0700
> Cc: 76322 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.