GNU bug report logs - #67687
Feature request: automatic tags management

Previous Next

Full log

Message #77 received at 67687 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Stefan Kangas <stefankangas <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 67687 <at> debbugs.gnu.org, eskinjp <at> gmail.com
Subject: Re: bug#67687: Feature request: automatic tags management
Date: Sun, 31 Dec 2023 01:58:55 +0200

On 31/12/2023 01:25, Stefan Kangas wrote:
> Dmitry Gutov <dmitry <at> gutov.dev> writes:
> 
>> On 30/12/2023 22:31, Stefan Kangas wrote:
>>
>>> Would it be helpful to put that explanation in the .dir-locals.el file
>>> itself?
>>
>> .dir-locals.el already usually hosts per-project settings. And most
>> users of this feature probably aren't going to read Emacs's one.
> 
> I was mostly thinking about us poor Emacs maintainers, but either way is
> fine by me.

Speaking of maintainers, I'm curious if I'll ever see the day when 'make 
tags' outputs "Use 'M-x etags-regen-mode' instead" ;-)

>> Yeah, it's hardly an innovation, more like in the "why don't we have
>> this yet" department. But while automatic indexing has been around for a
>> while, having it OOtB in lightweight editors wasn't commonplace. So as I
>> recall it for ST3 (first beta in 2013, release in 2017) it was a
>> meaningful step forward. The complex IDEs already had this for a long
>> time, of course (but each was more specialized, and worked with a
>> smaller number of languages).
> 
> OK, that's interesting, as far as text editor history goes.
> 
> Still, I'm hesitant to give them too much acknowledgement for what
> basically amounts to no longer being among the worst in class.  As you
> say, IDEs have already been doing this type of thing for a long time.
> Sublime Text is non-free software too, which doesn't do much to make me
> happier about mentioning their name.

GNU software has a long history of taking inspiration from non-free 
software, though.

> But if you think it's a useful piece of history, then by all means let's
> keep it.  Perhaps it could be moved to a separate history section rather
> than the introductory paragraph, though?  It's your call.

Nah, let's keep your alternative. I might mention it somewhere later, 
e.g. in a blog post.

>>> Indeed, the possible confusion with eglot could bear some documenting.
>>> Perhaps we should add a new paragraph to the commentary explaining how
>>> this feature will (or will not) interact with Eglot.
>>
>> Suggestions welcome. I'm not sure how to phrase that without mentioning
>> etags, tags files, and xref backends (in general and the names of
>> specific ones).
> 
> The most pressing thing to explain, I think, is what happens if you run
> both this mode and eglot.  Users will want to run the global mode but
> still use eglot for some projects.

Or lsp-mode, or cider, or a bunch of other Xref and completion backends 
that are still around but are less popular than LSP.

Oh BTW elisp-mode will also continue to use its own backends, unaffected 
by etags-regen-mode (unless xref-etags-mode is on), even if we decide to 
mention only the built-in solutions.

> I don't really have a concrete suggestion, as I don't have a clear idea
> of how it works.  :-)  But I think eglot will just take over and the
> etags stuff will be ignored, no?

In Eglot-managed buffers -- yes.

Previous Next

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