bug#67687: Feature request: automatic tags management

[Dmitry Gutov <dmitry@gutov.dev>]

On 31/12/2023 18:42, Eli Zaretskii wrote:
>> Date: Sun, 31 Dec 2023 17:25:35 +0200
>> Cc: eskinjp@gmail.com, 67687@debbugs.gnu.org, michael.albinus@gmx.de
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>> On 31/12/2023 08:34, Eli Zaretskii wrote:
>>>> +Note that this feature disables itself if you have already manually
>>>> +visited a tags table (with @kbd{M-x visit-tags-table}, or through an
>>>> +explicit prompt triggered by some feature that requires tags).
>>> This aspect is IMO somewhat problematic.  I wasn't aware of it, and
>>> now that I read this, I'm not sure it is correct and will meet user
>>> expectations.
>>
>> I'm pretty sure you asked for it: that even when this mode is on, it
>> shouldn't interfere with completion tables explicitly visited by the user.
> 
> "Interfere" and "prevent automatic regeneration" is not the same.
> 
> I think this probably warrants a separate defcustom: some people might
> want such regeneration, even if the tags table was loaded manually,
> others won't.  And I think the default should be to regenerate them
> regardless.

Like mentioned previously, I think we'll get such an option sooner or 
later, but not in the first check-in. It merits an additional 
discussion, at least.

>> And either way it seems like a prerequisite for enabling
>> etags-regen-mode by default sometimes in the future.
> 
> How so?  The fact that I loaded TAGS doesn't necessarily mean I don't
> want it updated when the sources change.  Or what am I missing?

a) We won't add new files to the index, because we (apparently) can't 
simply use the project's list of files -- there is no guarantee that it 
matches the fileset that the original author of the TAGS file had in mind.

b) There is no way to pick up the --regex options used for generating 
the original TAGS, or any other options we don't know about. So if we 
were to just use the logic of regenerating tags for newly changed files, 
we would end up with a mix of tags in some files based on the set of 
--regex used in the past, and with tags for new files based on the 
configured set of --regex options.

Either way, we get a poorly-defined behavior with edge cases that are 
likely to surprise the user at different points of time. So we might 
indeed grow such a capability, but it'll probably stay off by default.