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

Previous Next

Full log

View this message in rfc822 format

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

On 09/10/2024 22:11, Eli Zaretskii wrote:

>> This is basically a "uniqueness" operation using linear search, O(N^2).
> 
> Yes, this seems to be a protection against the same file name
> mentioned more than once on the command line..

Or, maybe more likely, against having symlinks scanned if the symlink 
target is also in the passed list.

>> Is there a hash table we could use?
> 
> Something like that should do, yes.

Can we use search.h? hcreate/hsearch/etc. IIUC it's on in the C stndard, 
and 
https://www.gnu.org/savannah-checkouts/gnu/gnulib/manual/html_node/hcreate.html 
says it's available on certain platforms.

>> Or perhaps we would skip the search when the canonicalized name is the
>> same as the original one.
> 
> That's not the same as the loop above does, I think.

If we assumed the duplicate check is only necessary for symlinks, and 
there is on average a small number of them, I think we could avoid using 
a hash table. But passing the same exact file 2 times would result in 
duplicate tags.

>> I guess someone might ask for flag "--no-decompress", sometime.
> 
> Yes, but it's also easy to exclude them via 'find'.

Or through etags-regen-ignores.

>>>    . Some files have their language identified by means other than their
>>>      names or extensions: those are the languages that have
>>>      "interpreters" defined in etags.c.  Shell scripts is one such case,
>>>      but not the only one.  So when etags-regen.el passes only files
>>>      with known extensions to etags, it misses those files from TAGS.
>>>      As one example, the file js/src/devtools/rootAnalysis/run_complete
>>>      in the gecko-dev tree is a Perl script, but has no .pl extension.
>>
>> This sounds the same as the "hashbang" files that we mentioned
>> previously. It makes sense for the scan to take longer, of course,
>> proportional to the number of the detected files.
> 
> My point was that if someone wants all the Python files, say,
> submitting only Python extensions to etags might miss some Python
> scripts.

Yes, that's the problem from the first comments of this report: to have 
hashbang files scanned, one can't use a whitelist of extensions. Using a 
blacklist should be fine, though.

Previous Next

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