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

[Dmitry Gutov]

On 20/09/2024 22:11, Eli Zaretskii wrote:
> > 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.

I have no objections, if you're sure about misdetecion. Though note that 
the current logic only supports specifying extensions. So no 
Makefile/Rakefile/etc.

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

Even for .m we ultimately delegate to etags' internal detector, since 
etags-regen-mode just chooses which files to send to it.

If ObjC has priority, and the parser has some internal heuristics as 
well that would help it choose, it'll be fine.

.m could also be Matlab/Octave, though.

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

I'm not sure which options or regexps it can add to the invocation. The 
problem is that the list would need to be exhaustive.

> Or maybe we should
> add an option to etags to disable the fallback to Fortran.

If someone were to implement that, it might solve two problems as once.