bug#26181: Remove etags

bug#26181: Remove etags

[Glenn Morris]

Package: emacs
Severity: wishlist
Version: 25.2

I've never understood why Emacs includes a tags program.
It's not part of the normal remit of a text editor.

This was previously discussed:
http://lists.gnu.org/archive/html/emacs-devel/2007-01/msg00075.html

It sounds like the answer is "historical reasons".
The situation has changed since then in that etags no longer has a
maintainer (IIUC).

I would like to suggest removing etags so that the time saved can be
spent on other things.

Having our own tags program means we can tweak it to work better for our
own code; but conversely it would be better if our code Just Worked with
standard (ie external) tools.

bug#26181: Remove etags

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Sun, 19 Mar 2017 19:15:18 -0400
> 
> I would like to suggest removing etags so that the time saved can be
> spent on other things.

What is considered a replacement?  The two I know about, GNU Global
and Exuberant ctags, don't have support for some of the languages we
support in etags (e.g., Ada).  And Exuberant ctags seems not to be
developed anymore(?).

bug#26181: Remove etags

[Andreas Politz]

Eli Zaretskii <eliz@gnu.org> writes:

> And Exuberant ctags seems not to be developed anymore(?).

There is an effort to continue development.

https://github.com/universal-ctags/ctags

-ap

bug#26181: Remove etags

[Dmitry Gutov]

On 20.03.2017 01:15, Glenn Morris wrote:

> I've never understood why Emacs includes a tags program.
> It's not part of the normal remit of a text editor.

FWIW, it has been handy when we introduced xref and started treating the 
tags a bit more strictly.

> The situation has changed since then in that etags no longer has a
> maintainer (IIUC).

AFAIK Eli is the maintainer now. And it's handy to have for now, at 
least until Universal Ctags is widely available across distributions, 
handles all languages as well as etags does, and outputs correct entries 
WRT implicit/explicit tag names (not 100% sure there is a problem, but 
it's something that we had to fix in etags recently, at least).

Having all these conditions satisfied seems to be a .

> Having our own tags program means we can tweak it to work better for our
> own code; but conversely it would be better if our code Just Worked with
> standard (ie external) tools.

The latter might mean learning to use the ctags output (Vim format).

bug#26181: Remove etags

[Francesco Potortì]

Dmitry Gutov:
>AFAIK Eli is the maintainer now. And it's handy to have for now, at 
>least until Universal Ctags is widely available across distributions, 
>handles all languages as well as etags does, and outputs correct entries 
>WRT implicit/explicit tag names (not 100% sure there is a problem, but 
>it's something that we had to fix in etags recently, at least).

I agree.  Generally speaking, etags requires little maintenance, being
mature (sorry for not being able to provide even this little maintenance
any more).  Certainly less than having to manage an external tool.

Glenn Morris:
>> Having our own tags program means we can tweak it to work better for our
>> own code; but conversely it would be better if our code Just Worked with
>> standard (ie external) tools.
>
>The latter might mean learning to use the ctags output (Vim format).

Only if the above conditions are satisfied, plus having the same amount
of information and not much bigger size.

bug#26181: Remove etags

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 21 Mar 2017 11:03:24 +0200
> 
> And [etags is] handy to have for now, at least until Universal Ctags
> is widely available across distributions

This indeed seems like the most important prerequisite, because the
command-line options accepted by Universal ctags are incompatible with
those of etags, so supporting both would be a pain.

> > Having our own tags program means we can tweak it to work better for our
> > own code; but conversely it would be better if our code Just Worked with
> > standard (ie external) tools.
> 
> The latter might mean learning to use the ctags output (Vim format).

You mean, if we want to support tools beyond Universal ctags?
(Because the latter supports Emacs-compatible TAGS output.)  Yes, if
we want to support other tools, we'd need to extend etags.el or rely
on external packages for parsing their tags tables.  E.g. GNU Global
doesn't support TAGS format even as an option, AFAIK.

bug#26181: Remove etags

[Dmitry Gutov]

On 21.03.2017 17:42, Eli Zaretskii wrote:

>> The latter might mean learning to use the ctags output (Vim format).
> 
> You mean, if we want to support tools beyond Universal ctags?

Not what I meant.

> (Because the latter supports Emacs-compatible TAGS output.) 

It officially does, but if etags is no more, the TAGS format has no 
reference implementation, and thus becomes less relevant and harder to 
conform to.

The Vim tags format is clearly more important to a program like ctags, 
so we might want to get to supporting that. It's also more rich, IIUC.

> Yes, if
> we want to support other tools, we'd need to extend etags.el or rely
> on external packages for parsing their tags tables.  E.g. GNU Global
> doesn't support TAGS format even as an option, AFAIK.

True. For Global, I think the vast majority of code in etags.el becomes 
irrelevant.

bug#26181: Remove etags

[John Wiegley]

>>>>> "GM" == Glenn Morris <rgm@gnu.org> writes:

GM> I've never understood why Emacs includes a tags program. It's not part of
GM> the normal remit of a text editor.

That description applies to the majority of what Emacs has become today. :)

ctags is included because it's an auxiliary program to extend the ability of
Emacs to jump around code. That it's not implement in Emacs Lisp, or the C
core of Emacs itself, is really beside the point. For all intents and
purposes, it's part of what Emacs offers to the *user*, and I bet there are
many users who aren't even aware that it's a separate program.

GM> I would like to suggest removing etags so that the time saved can be spent
GM> on other things.

I appreciate your desire to optimize our project management burdens, but this
is better mentioned on emacs-devel than a bug report.

Removing etags will not increase the time spent on other things. You yourself
can ignore etags, and spend your time elsewhere, but as long as someone is
willing to keep working on etags, then by definition that is where they choose
to spend their time. I could take away the opportunity, certainly, but I can't
then allocate the time it would free up.

If no one is maintaining something, *and* no one is using it, that's the time
to consider deprecation and eventual removal.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

bug#26181: Remove etags

[Glenn Morris]

PS I should have suggested this initially, but why not split it off into
a separate project from Emacs? Bundling unrelated packages into one
project is generally bad form.

bug#26181: Remove etags

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

etags exists for Emacs.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

bug#26181: Remove etags

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> etags exists for Emacs.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

There didn't seem to be much enthusiasm from anybody in removing etags
from Emacs, so I'm therefore closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no