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