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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 21 Sep 2024 16:48:22 +0300
> Cc: spwhitton@spwhitton.name, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 21/09/2024 10:03, Eli Zaretskii wrote:
> 
> >> Maybe do that on master, though.
> > 
> > Why on master? what's the danger of doing this on the release branch?
> > No code is changed, only data, and it only affects the files that
> > etags would tag anyway.
> > 
> >> Scanning for tags in files that aren't considered code like .html or
> >> .texi, etc might create a lot more navigation locations, not all of them
> >> wanted in 'C-u M-.' completion.
> >>
> >> I'm not actually sure it will be a problem, but it seems like a major
> >> enough change to allow for user feedback first.
> > 
> > But etags-regen is not only about completion, is it?  Its main
> > purpose, AFAIU, is to automatically regenerate tags tables when they
> > are outdated.  Or what am I missing?
> 
> I've never generated tags for HTML or Texinfo files, and didn't really 
> think about it as an option. Do you?

If you have reservations about some of the extensions, let's exclude
them for now.  I believe there are just a few of them, while the vast
majority should present no problem, right?  I'm okay with leaving out
HTML and Texinfo.  Are there more of those?  TeX, perhaps?

> So I suggest drawing the line somewhere between tags for text and tags 
> for code. We can add all the programming file extensions in emacs-30 and 
> for 31 somebody might implement the "no Fortran fallback" option, so we 
> might drop the list of extensions altogether. We would have time to 
> restore it before the next release, though, if particular problems come 
> up (e.g. drop in performance).

Fine by me, thanks.