bug#67687: Feature request: automatic tags management

[Dmitry Gutov]

On 31/12/2023 09:23, Eli Zaretskii wrote:
> > Date: Sun, 31 Dec 2023 01:58:55 +0200
> > Cc: 67687@debbugs.gnu.org, eskinjp@gmail.com
> > From: Dmitry Gutov <dmitry@gutov.dev>
> >
> > 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" ;-)
>
> I don't yet see why we'd need that.

There is no hard requirement indeed.

> As one data point, my TAGS files
> in the Emacs repository were generated in Feb 2023, and I still use
> them almost every day without any visible problems.  And for Lisp
> code, M-. doesn't use TAGS by default anyway.
>
> Unlike "indexing" in other IDEs, the Emacs tags commands are well
> equipped to cope with changes in sources, and don't fail
> catastrophically when there are such changes, as long as functions and
> variables don't move between files.  The auto-regen mode might be
> needed for some projects where source files change significantly at
> high pace, but not in Emacs, at least not IME.

The upside is not having to generate tags to begin with (e.g. for new 
contributors, or new repository checkouts/worktrees/etc), and not 
worrying about keeping them updated even when you add or remove a 
function. No matter how rare, that still happens.

There are some downsides too (e.g. some runtime overhead), let's wait 
and see if those turn out to be noticeable enough.

> So whether this mode should be turned on by default is something that
> is yet to be seen.  Let's not hurry and make decisions in haste,
> certainly not wrt the use of this as part of Emacs maintenance.

I'm not proposing any haste in that respect.