bug#67687: Feature request: automatic tags management

[Dmitry Gutov]

On 31/12/2023 21:27, Eli Zaretskii wrote:
> > Date: Sun, 31 Dec 2023 19:53:27 +0200
> > Cc: stefankangas@gmail.com, eskinjp@gmail.com, 67687@debbugs.gnu.org,
> >   michael.albinus@gmx.de
> > From: Dmitry Gutov <dmitry@gutov.dev>
> >
> > > > 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.
>
> The user has etags-regen-ignores to control that.

etags-regen-ignores wouldn't normally include filters that already are 
in project's ignores. But of course the user might choose to add them.

> > 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.
>
> There are defcustoms to control both of those.

If all of these options are set to the expected values, what's stopping 
the user from calling 'M-x tags-reset-tags-tables' and having 
etags-regen-mode create the table on its own? The extra 10 seconds of 
waiting?

Also note that if you have an existing TAGS file in the root of the 
project, with default configuration etags-regen-mode will pick it up to 
visit and refresh it where necessary (when there are changed or missing 
files).

> > 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.
>
> I agree that sometimes it could be against the user's expectations.
> But I also think that other times it is according to user's
> expectations.  Which tells me that this is a separate issue that needs
> a separate knob; we shouldn't deterministically deduce what users want
> in this respect from the fact that he/she loaded an existing tags
> table.  Moreover, it is quite possible that even when the mode is
> turned on, users might want sometimes to load tags tables manually.

I don't mind adding additional knobs.