bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#67687: Feature request: automatic tags management


From: Dmitry Gutov
Subject: bug#67687: Feature request: automatic tags management
Date: Sun, 31 Dec 2023 01:58:55 +0200
User-agent: Mozilla Thunderbird

On 31/12/2023 01:25, Stefan Kangas wrote:
Dmitry Gutov <dmitry@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]