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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 2 Oct 2024 21:00:58 +0300
> Cc: spwhitton@spwhitton.name, 73484@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 02/10/2024 14:28, Eli Zaretskii wrote:
> >> Date: Tue, 1 Oct 2024 02:19:17 +0300
> >> Cc: spwhitton@spwhitton.name, 73484@debbugs.gnu.org
> >> From: Dmitry Gutov <dmitry@gutov.dev>
> >>
> >> Just do nothing.
> > 
> > Doing nothing means the file's name will not appear at all in TAGS.  I
> > don't think that's TRT, since every file submitted to etags should be
> > mentioned in TAGS for the benefit of tags-search and similar features.
> 
> Hmm, maybe another flag, then?
> 
> Including many unrelated files would just bloat the tags file for little 
> reason. And unlike manual generation, it's not like the user asked for 
> all of them to be included.

What do we tell to users of tags-search and its ilk?

> > So I currently tend to modify etags such that if no language was
> > detected by the file's name/extension, and this new no-fallbacks
> > option was specified, etags will behave as if given --language=none
> > (which also means that if any regexps were specified, they will be
> > processed correctly for such files).
> 
> Any regexps for "all" files, right?

The rules for regexps don't change: each regexp applies to the files
that follow it on the command line.

> ...but if there are no matches I'd prefer the files to be skipped. The 
> files detected as type 'none' anyway.

I don't like this, and I think this is misguided.  I also don't see
any special problem with having lines that name files in TAGS, it
isn't like the size of TAGS will grow significantly or its processing
will be significantly slower.  IOW, this sounds like a clear case of
premature optimization.