bug#73484: 31.0.50; Abolishing etags-regen-file-extensions

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 4 Oct 2024 04:25:15 +0300
> Cc: spwhitton@spwhitton.name, 73484@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> >> Previously, when building a TAGS file manually, a developer in such a
> >> project specified a list of file globs by hand. One that would be
> >> limited to .[ch] files, and maybe .y as well, but not all the files in
> >> the directory.
> > 
> > If they definitely do NOT want the other files to be present in TAGS,
> > they can keep using those globs.  Nothing will change in that case.
> 
> a) They would have to produce the same list of file extensions that we 
> are using now, and they will need to find out which variable to 
> customize, to set to that list.
> 
> b) They won't get the shebang detection capability, unless we add a new 
> option where they will have to enumerate all their shebang-enabled file 
> names as well.
> 
> So it seems like they would have to choose between the one and the 
> other, with the end behavior that I'm describing not being supported 
> even any combination of user options.

They will need to choose only if they want improvements.  To have the
same behavior, with the same downsides as before, they need not change
anything.  IOW, the change I propose does no harm to those projects.

And if shebang detection is desired, the choice is quite obvious, if
you ask me: submit all the files.  The downside is making TAGS larger
and having more file names in it, which I think is a very small
downside, if at all, compared to advantages.

So once again, I think this is a premature optimization.  The downside
of a larger TAGS will only have tangible effects in huge trees.

> > The fact that in the scenario you describe above 2K more files will
> > appear in tags-search is, from my POV, an argument _for_ including
> > them, not against: we have no reason to assume that users don't want
> > to search those files for some regexp, because regexps specified in
> > tags-search don't necessarily have anything to do with the identifiers
> > we tag.  A valid case in point is to look up all references to some
> > file when the file is deleted, or references to some version when the
> > version is updated: we definitely want files like README and INSTALL
> > to be included in the search.
> 
> I would hope that project-find-regexp works well enough for that. Or 
> 'M-x project-search' for the fans of the classic interface.

Maybe, but we do still want to keep tags-search, so the existence of
other commands don't invalidate my argument above.

> README and INSTALL are not currently included in TAGS. You seem to be 
> making a case that all files in our dev repository should be included, 
> but for some reason the current build rules are very different?

I'm not talking specifically about Emacs, because README and INSTALL
are typically present in many packages.  In our case, we don't pass
them to etags for historical reasons (we have admin/*.el stuff to help
us modify the version string in all the files that reference it, for
example), but it is quite plausible that if we had this option back
then, we could have used etags to help.  For example, one downside of
what we have in admin.el is that the list of files to edit when we
bump the version is maintained by hand, which is error-prone: we just
had an instance of this when exec/configure.ac was added and we forgot
to update admin.el according.  Using etags would have allowed us to
avoid such problems.

If we want a separate optional behavior that prevents files with no
tags from being mentioned in TAGS, I'd argue that such an option
should affect all the scanned files, not just those whose language
could not be determined from their names.