bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Francesco Potortì
Subject: bug#73484: 31.0.50; Abolishing etags-regen-file-extensions
Date: Sun, 29 Sep 2024 19:15:57 +0200

Eli Zaretskii:
>> I understand that we need to disable the Fortran and C fallbacks to
>> avoid false positives, but what do we want to do if the fallbacks are
>> disabled and no suitable language parser is found using the file name?
>> Just skip the file and do nothing? emit a warning? something else?

Eli Zaretskii:
>Wait a minute... we already have "--language=none", which means only
>do regexp processing, if any.  If no regexps were specified, 'none'
>produces a single entry for a file, stating just its name, like this:
>
>  ^L
>  foo,0
>
>where ^L is a literal \f character.  Is the intent here to prevent
>even that from being written to TAGS?  If not, then we don't need any
>new command-line option; instead, etags-regen could simply pass the
>"--language=none" option before each file with no extension, and be
>done, no?
>
>Or maybe this is "the missing link" between this and the shebang
>processing?

If you set language=none for files whose extension is unknown to Etags, then 
you give up on shebang processing.  If you do not set language=none and Etags 
does not recognise any shebang, it defaults to Fortran.  If it does not find 
any Fortran tags, it defaults to C/C++.  When default processing happens on a 
file which is neither Fortran nor C/C++, it usually generates no tags, but may 
occasionally generate fake tags.

AFAIU, the problem is that there are use cases when you have to feed Etags with 
files that should generate no tags, yet the occasional fake tags are not 
tolerable.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]