GNU bug report logs -
#73484
31.0.50; Abolishing etags-regen-file-extensions
Previous Next
Full log
View this message in rfc822 format
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.
This bug report was last modified 225 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.