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

[Dmitry Gutov <dmitry@gutov.dev>]

On 01/10/2024 18:00, Eli Zaretskii wrote:

>> Just do nothing. We'd really want to delegate language detection to
>> etags rather than doing it inside Elisp - the latter is slower and
>> ultimately more limited. But for that etags needs to have a reliable
>> detection logic, one without too many false positives (and IME false
>> positives here are worse than false negatives, because scanning too much
>> can often mean both wrong tags and long scans, and a completion table
>> that gets too large because of bogus tags).
> 
> I'm not sure I understand: if you worry about performance, then
> disabling fallbacks will not eliminate all of the cases where etags
> scans the entire file or at least some of its portions.

etags's scanning should still be faster than doing it in Lisp, or the 
subsequent calls to tags-completion-table or etags--xref-find-definitions.

Further, the last function would repeatedly search through the tags 
file, so it's important to keep tags' scanner accuracy high: without 
incorrectly recognized files, and without wrong index entries.

> Can you explain to me again what exactly is the problem with the
> fallbacks in the context of etags-regen?

We've talked about this before, here's my previous reply: 
https://lists.gnu.org/archive/html/emacs-devel/2018-01/msg00387.html

I don't have the same experiment at hand, but the past me seems to be 
saying that scanning files incorrectly can also make the whole scan take 
longer, considerably. And make the resulting file bigger, which makes 
its parsing from Emacs slower as well, and so on.