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

From: Dmitry Gutov <[email-masked]>
Date: Sat, 5 Oct 2024 02:01:14 +0300

On 04/10/2024 09:45, Eli Zaretskii wrote:

> 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.

We did talk about changing the default of etags-regen-file-extensions to 
t. I suppose it's debatable.

> 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.

FWIW, TAGS for gecko-dev (Mozilla's repository which I have here for 
testing) takes ~30 seconds to generate and ~400ms to find a definition 
for the set of files to scan that I currently have set up. Both timings 
seem quite impactful for user experience. I imagine some Emacs users 
work at Mozilla, though that's only a guess.

If someone were to provide a patch for etags with new functionality 
(disabling fallbacks, at least), I could benchmark and come back with 
numbers. And if experimental flags are available, with numbers for those 
as well.

>>> 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.

In my mind, tags-search is for files that are code-related. Actual users 
might differ, though.

>> 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.

Some other aspects of having more false positives would come up as a 
result, probably. But it might be worth testing.

> 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.

I don't have a strong opinion here, just that it would depart from my 
mental model mentioned above, of having all code-related files listed. 
For example by missing some newly added .c file where no function 
definitions have been added yet; 'M-x tags-search' would skip it.

If that makes sense to you, okay.