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

From: Dmitry Gutov <[email-masked]>
Date: Sat, 30 Dec 2023 03:50:03 +0200

On 30/12/2023 00:29, Stefan Kangas wrote:
> Dmitry Gutov <[email-masked]> writes:
> 
>> Fixed a typo in dir-locals and implemented better support for
>> etags-regen-ignores (though with one omission).
>>
>> To me it looks good to check in now.
> 
> Thanks for working on this long overdue feature.
> 
> Do we really need a minor mode for this, or should it just be a
> defcustom in etags?  We have tons of minor modes for this or that
> various minor feature, and the list in e.g. `C-h m' is really starting
> to look really long, at least in my use.  I wonder whether that is
> really justified.

As long as it's in a separate file, it should be easy to publish it to 
ELPA (as "core" package). Which is an option that's nice to have, even 
if not essential. Sometime later, when the features and implementation 
stabilize, we could merge the files, leaving the code in ELPA for older 
emacsen. Or something like that.

>> diff --git a/.dir-locals.el b/.dir-locals.el
>> index e087aa89cd1..ce7febca851 100644
>> --- a/.dir-locals.el
>> +++ b/.dir-locals.el
>> @@ -8,6 +8,12 @@
>>            (vc-git-annotate-switches . "-w")
>>            (bug-reference-url-format . "https://debbugs.gnu.org/%s")
>>   	 (diff-add-log-use-relative-names . t)
>> +         (etags-regen-regexp-alist
>> +          .
>> +          ((("c" "objc") .
>> +            ("/[ \t]*DEFVAR_[A-Z_ \t(]+\"\\([^\"]+\\)\"/\\1/"
>> +             "/[ \t]*DEFVAR_[A-Z_ \t(]+\"[^\"]+\",[ \t]\\([A-Za-z0-9_]+\\)/\\1/"))))
>> +         (etags-regen-ignores . ("test/manual/etags/"))
> 
> I'm not terribly familiar with how etags is implemented, so please
> forgive me if some of these questions are naive.
> 
> Is there any way around having to do so much manual setup to get this to
> work?  The above regexp is rather complex.
> 
> And is the idea that users will customize this by themselves?  Is it
> feasible to shift most of that work to major mode authors [perhaps only
> partially]?

This is only necessary for language constructs not supported by etags 
OOtB. Such as our C macros which define Elisp functions and variables. 
These are the same regexps that we have in our Makefile.

So this is a per-project thing, rather than per-language. Most users and 
projects shouldn't need it, or wouldn't need it right away.

>> diff --git a/lisp/progmodes/etags-regen.el b/lisp/progmodes/etags-regen.el
>> new file mode 100644
>> index 00000000000..88b730195c3
>> --- /dev/null
>> +++ b/lisp/progmodes/etags-regen.el
>> @@ -0,0 +1,411 @@
>> +;;; etags-regen.el --- Auto-(re)regenerating tags  -*- lexical-binding: t -*-
>> +
>> +;; Copyright (C) 2021, 2023 Free Software Foundation, Inc.
> 
> Using just 2021-2023 here is fine.

Ok.

>> +;;; Commentary:
>> +
>> +;; Simple automatic tags generation with updates on save.
>> +;;
>> +;; The goal of this mode is to provide a feature that should be
>> +;; familiar to the users of certain lightweight programmer's editors,
>> +;; such as Sublime Text.  Which is "go to definition" with automatic
>> +;; indexing, added in ST3 (released in 2017).
> 
> This makes it sound like we're just copying others, when we could be
> more confident.  Emacs has had the described feature since before 2017.
> I propose dropping all references to Sublime Text and reducing the above
> to simply saying:

But... it didn't? Otherwise you wouldn't have called it "long overdue", 
right?

Anyway, I'm not married to the above text, it's just a description of 
how I'm thinking about the problem. But I would invite you and other to 
consider how the ST users take advantage of automatic indexing without 
having to be aware of how information is stored behind the scenes (tag 
files or not), when considering the sections of the manual touching on 
etags-regen-mode.

>      This library provides automatic indexing for Emacs "go to
>      definition" feature, the `xref-go-forward' command (bound to `M-.'
>      by default).

Sure.

We could also add some text that would distinguish it from the general 
notion of "automatic indexing", so that the users of Eglot, for example, 
don't consider it necessary to enable this mode. Even though they would 
also want indexing to remain automatic.

>> +;; At the moment reindexing works off before/after-save-hook, but to
>> +;; handle more complex changes (e.g. the user switching to another
> 
> (We usually prefer "for example" to "e.g.".)

No problem.

Though searching across the codebase, the number of hits for these two 
options seems to be about the same (5K vs 4K).