Subject: bug#67687: Feature request: automatic tags management

From: Dmitry Gutov <[email-masked]>
Date: Sun, 31 Dec 2023 17:31:17 +0200

On 31/12/2023 09:23, Eli Zaretskii wrote:
>> Date: Sun, 31 Dec 2023 01:58:55 +0200
>> Cc: [email-masked], [email-masked]
>> From: Dmitry Gutov <[email-masked]>
>>
>> On 31/12/2023 01:25, Stefan Kangas wrote:
>>> Dmitry Gutov <[email-masked]> 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.