From: Dmitry Gutov <dmitry@gutov.dev>
To: Stefan Kangas <stefankangas@gmail.com>, Eli Zaretskii <eliz@gnu.org>
Cc: 67687@debbugs.gnu.org, eskinjp@gmail.com
Subject: bug#67687: Feature request: automatic tags management
Date: Sun, 31 Dec 2023 01:58:55 +0200 [thread overview]
Message-ID: <2ee5f84b-868e-4f7c-9c82-58234c4677a1@gutov.dev> (raw)
In-Reply-To: <CADwFkm=AL9TRDnx5Nb=6-mq-UQ8yacBdsA5Po_OcnWOQRp045g@mail.gmail.com>
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.
next prev parent reply other threads:[~2023-12-30 23:58 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-07 11:43 bug#67687: Feature request: automatic tags management Jon Eskin
2023-12-07 15:57 ` Dmitry Gutov
2023-12-07 19:57 ` Jon Eskin
2023-12-10 2:41 ` Dmitry Gutov
2023-12-10 11:38 ` Jon Eskin
2023-12-20 21:11 ` Jon Eskin
2023-12-21 0:24 ` Dmitry Gutov
2023-12-21 7:40 ` Eli Zaretskii
2023-12-21 16:46 ` Dmitry Gutov
2023-12-21 23:37 ` Dmitry Gutov
2023-12-24 1:43 ` Dmitry Gutov
2023-12-28 9:30 ` Eli Zaretskii
2023-12-30 3:05 ` Dmitry Gutov
2023-12-30 7:33 ` Eli Zaretskii
2023-12-30 23:43 ` Dmitry Gutov
2023-12-31 1:02 ` Stefan Kangas
2023-12-31 23:29 ` Dmitry Gutov
2024-01-02 0:40 ` Stefan Kangas
2024-01-02 1:31 ` Dmitry Gutov
2023-12-31 7:07 ` Eli Zaretskii
2023-12-31 15:21 ` Dmitry Gutov
2023-12-29 22:29 ` Stefan Kangas
2023-12-30 1:50 ` Dmitry Gutov
2023-12-30 20:31 ` Stefan Kangas
2023-12-30 22:50 ` Dmitry Gutov
2023-12-30 23:25 ` Stefan Kangas
2023-12-30 23:58 ` Dmitry Gutov [this message]
2023-12-31 7:23 ` Eli Zaretskii
2023-12-31 15:31 ` Dmitry Gutov
2023-12-29 22:17 ` Stefan Kangas
2023-12-30 1:31 ` Dmitry Gutov
2023-12-30 20:56 ` Stefan Kangas
2023-12-30 23:23 ` Dmitry Gutov
2023-12-31 0:03 ` Stefan Kangas
2023-12-31 6:34 ` Eli Zaretskii
2023-12-31 7:22 ` Stefan Kangas
2023-12-31 15:22 ` Dmitry Gutov
2023-12-31 15:25 ` Dmitry Gutov
2023-12-31 16:42 ` Eli Zaretskii
2023-12-31 17:53 ` Dmitry Gutov
2023-12-31 19:27 ` Eli Zaretskii
2024-01-01 1:23 ` Dmitry Gutov
2024-01-01 12:07 ` Eli Zaretskii
2024-01-01 15:47 ` Dmitry Gutov
2024-01-01 16:50 ` Eli Zaretskii
2024-01-01 17:23 ` Dmitry Gutov
2024-01-01 17:39 ` Eli Zaretskii
2024-01-01 18:48 ` Dmitry Gutov
2024-01-01 19:25 ` Eli Zaretskii
2024-01-02 1:40 ` Dmitry Gutov
2024-01-04 1:56 ` Dmitry Gutov
2024-01-02 10:41 ` Francesco Potortì
2024-01-02 13:09 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2ee5f84b-868e-4f7c-9c82-58234c4677a1@gutov.dev \
--to=dmitry@gutov.dev \
--cc=67687@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=eskinjp@gmail.com \
--cc=stefankangas@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.