GNU bug report logs - #73484
31.0.50; Abolishing etags-regen-file-extensions

Previous Next

Full log

Message #44 received at 73484 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 73484 <at> debbugs.gnu.org, spwhitton <at> spwhitton.name
Subject: Re: bug#73484: 31.0.50; Abolishing etags-regen-file-extensions
Date: Thu, 3 Oct 2024 01:03:14 +0300

On 02/10/2024 21:56, Eli Zaretskii wrote:
>> Date: Wed, 2 Oct 2024 21:00:58 +0300
>> Cc: spwhitton <at> spwhitton.name, 73484 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dmitry <at> gutov.dev>
>>
>> On 02/10/2024 14:28, Eli Zaretskii wrote:
>>>> Date: Tue, 1 Oct 2024 02:19:17 +0300
>>>> Cc: spwhitton <at> spwhitton.name, 73484 <at> debbugs.gnu.org
>>>> From: Dmitry Gutov <dmitry <at> 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?

We can consider how most of such users' indexes look. See below.

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

This seems okay.

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

I could do some experiments, if you post preliminary support of that 
flag, with "empty" files in TAGS and without.

But here's how I'm looking at it:

Imagine a straightforward C project, one that has .c files, .h, maybe 
.y, and also a bunch of docs, build artefacts (some of them checked in), 
and maybe other data files as well. Also README, ChangeLog, Makefile, 
config.bat, some .txt files, many other files without extensions, etc.

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.

To use Emacs itself as an example, the 'tags' target in our own Makefile 
only includes .[hc], .m, .cc, .el and (surprising to me) .texi files. 
But not any of the others. The number of such files is ~3K, if I'm 
counting correctly.

The total number of all non-ignored files in our repo is ~5K. That's 2K 
more files that would be present in the 'M-x tags-search' or 'M-x 
list-tags' outputs, if an Emacs developer simply switches to using 
etags-regen-mode, and etags-regen-mode drops the file extensions 
whitelist, and etags keeps all passed files' names in its output.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.