Re: Missing entries for Perl in etags-regen-file-extensions -- okay for emacs-30?

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 20 Sep 2024 21:20:59 +0300
> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> >>> We already have "pl" in the list.  Adding "pm" is okay, but then why
> >>> only it? why not add all the extensions that 'etags' supports?
> 
> Adding "pm" sounds good.
> 
> "All supported extensions" (or most) might be a good idea as well.

So I think we should add all of them on emacs-30.

> As long as the additions are not misdetected often - false positives 
> based on obscure languages might be a nuisance.

Agreed.  But it sounds like the only such case is .m, which could be
Mercury, not just ObjC.

> >> Okay thanks, I'll add "pm" so we don't have just one Perl extension, and
> >> hopefully we can figure out a better solution for master.
> > My question about adding more extensions was for emacs-30.
> > 
> > Let's wait for Dmitry to chime in, and take it from there.
> 
> The reason why is that etags parses files with unknown extensions as 
> Fortran sources, and there is currently no opt-out. See this thread:
> 
> https://lists.gnu.org/archive/html/emacs-devel/2018-01/msg00323.html
> 
> The same issue stops us from benefiting from etags' hashbang detection.

Right.  These require to explicitly specify --language on the etags
command line.  So maybe etags-regen could learn to apply special
command-line options to files matching a regexp.  Or maybe we should
add an option to etags to disable the fallback to Fortran.