unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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.





  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

  List information: https://www.gnu.org/software/emacs/

* 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).