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

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

[Sean Whitton]

Hello,

Can I install this simple change on the release branch, please?

-- >8 --
---
 lisp/progmodes/etags-regen.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/progmodes/etags-regen.el b/lisp/progmodes/etags-regen.el
index 21ea9bfb8b3..e97b0cd7574 100644
--- a/lisp/progmodes/etags-regen.el
+++ b/lisp/progmodes/etags-regen.el
@@ -119,7 +119,7 @@ etags-regen-regexp-alist
 ;; http://lists.gnu.org/archive/html/emacs-devel/2018-01/msg00323.html
 (defcustom etags-regen-file-extensions
   '("rb" "js" "py" "pl" "el" "c" "cpp" "cc" "h" "hh" "hpp"
-    "java" "go" "cl" "lisp" "prolog" "php" "erl" "hrl"
+    "java" "go" "cl" "lisp" "prolog" "php" "erl" "hrl" "pl" "pm"
     "F" "f" "f90" "for" "cs" "a" "asm" "ads" "adb" "ada")
   "Code file extensions for `etags-regen-mode'.
-- 
Sean Whitton

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

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Date: Fri, 20 Sep 2024 10:15:50 +0100
> 
> Hello,
> 
> Can I install this simple change on the release branch, please?
> 
> -- >8 --
> ---
>  lisp/progmodes/etags-regen.el | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lisp/progmodes/etags-regen.el b/lisp/progmodes/etags-regen.el
> index 21ea9bfb8b3..e97b0cd7574 100644
> --- a/lisp/progmodes/etags-regen.el
> +++ b/lisp/progmodes/etags-regen.el
> @@ -119,7 +119,7 @@ etags-regen-regexp-alist
>  ;; http://lists.gnu.org/archive/html/emacs-devel/2018-01/msg00323.html
>  (defcustom etags-regen-file-extensions
>    '("rb" "js" "py" "pl" "el" "c" "cpp" "cc" "h" "hh" "hpp"
> -    "java" "go" "cl" "lisp" "prolog" "php" "erl" "hrl"
> +    "java" "go" "cl" "lisp" "prolog" "php" "erl" "hrl" "pl" "pm"
>      "F" "f" "f90" "for" "cs" "a" "asm" "ads" "adb" "ada")
>    "Code file extensions for `etags-regen-mode'.

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?

Dmitry, why do we need an explicit list instead of asking 'etags'
which extensions it supports?

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

[Sean Whitton]

Hello,

On Fri 20 Sep 2024 at 01:34pm +03, Eli Zaretskii wrote:

>> From: Sean Whitton <spwhitton@spwhitton.name>
>> Date: Fri, 20 Sep 2024 10:15:50 +0100
>>
>> Hello,
>>
>> Can I install this simple change on the release branch, please?
>>
>> -- >8 --
>> ---
>>  lisp/progmodes/etags-regen.el | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/lisp/progmodes/etags-regen.el b/lisp/progmodes/etags-regen.el
>> index 21ea9bfb8b3..e97b0cd7574 100644
>> --- a/lisp/progmodes/etags-regen.el
>> +++ b/lisp/progmodes/etags-regen.el
>> @@ -119,7 +119,7 @@ etags-regen-regexp-alist
>>  ;; http://lists.gnu.org/archive/html/emacs-devel/2018-01/msg00323.html
>>  (defcustom etags-regen-file-extensions
>>    '("rb" "js" "py" "pl" "el" "c" "cpp" "cc" "h" "hh" "hpp"
>> -    "java" "go" "cl" "lisp" "prolog" "php" "erl" "hrl"
>> +    "java" "go" "cl" "lisp" "prolog" "php" "erl" "hrl" "pl" "pm"
>>      "F" "f" "f90" "for" "cs" "a" "asm" "ads" "adb" "ada")
>>    "Code file extensions for `etags-regen-mode'.
>
> 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?

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.

-- 
Sean Whitton

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

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: Dmitry Gutov <dmitry@gutov.dev>,  emacs-devel@gnu.org
> Date: Fri, 20 Sep 2024 14:39:11 +0100
> 
> Hello,
> 
> On Fri 20 Sep 2024 at 01:34pm +03, Eli Zaretskii wrote:
> 
> >> From: Sean Whitton <spwhitton@spwhitton.name>
> >> Date: Fri, 20 Sep 2024 10:15:50 +0100
> >>
> >> Hello,
> >>
> >> Can I install this simple change on the release branch, please?
> >>
> >> -- >8 --
> >> ---
> >>  lisp/progmodes/etags-regen.el | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/lisp/progmodes/etags-regen.el b/lisp/progmodes/etags-regen.el
> >> index 21ea9bfb8b3..e97b0cd7574 100644
> >> --- a/lisp/progmodes/etags-regen.el
> >> +++ b/lisp/progmodes/etags-regen.el
> >> @@ -119,7 +119,7 @@ etags-regen-regexp-alist
> >>  ;; http://lists.gnu.org/archive/html/emacs-devel/2018-01/msg00323.html
> >>  (defcustom etags-regen-file-extensions
> >>    '("rb" "js" "py" "pl" "el" "c" "cpp" "cc" "h" "hh" "hpp"
> >> -    "java" "go" "cl" "lisp" "prolog" "php" "erl" "hrl"
> >> +    "java" "go" "cl" "lisp" "prolog" "php" "erl" "hrl" "pl" "pm"
> >>      "F" "f" "f90" "for" "cs" "a" "asm" "ads" "adb" "ada")
> >>    "Code file extensions for `etags-regen-mode'.
> >
> > 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?
> 
> 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.

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

[Dmitry Gutov]

Hi!

On 20/09/2024 16:41, Eli Zaretskii wrote:
>>>> diff --git a/lisp/progmodes/etags-regen.el b/lisp/progmodes/etags-regen.el
>>>> index 21ea9bfb8b3..e97b0cd7574 100644
>>>> --- a/lisp/progmodes/etags-regen.el
>>>> +++ b/lisp/progmodes/etags-regen.el
>>>> @@ -119,7 +119,7 @@ etags-regen-regexp-alist
>>>>   ;;http://lists.gnu.org/archive/html/emacs-devel/2018-01/msg00323.html
>>>>   (defcustom etags-regen-file-extensions
>>>>     '("rb" "js" "py" "pl" "el" "c" "cpp" "cc" "h" "hh" "hpp"
>>>> -    "java" "go" "cl" "lisp" "prolog" "php" "erl" "hrl"
>>>> +    "java" "go" "cl" "lisp" "prolog" "php" "erl" "hrl" "pl" "pm"
>>>>       "F" "f" "f90" "for" "cs" "a" "asm" "ads" "adb" "ada")
>>>>     "Code file extensions for `etags-regen-mode'.
>>> 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.

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

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

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

[Eli Zaretskii]

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

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.

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

[Dmitry Gutov]

On 20/09/2024 22:35, Dmitry Gutov wrote:
>>> 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.

Maybe do that on master, though.

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.

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

[Eli Zaretskii]

> Date: Fri, 20 Sep 2024 22:59:35 +0300
> From: Dmitry Gutov <dmitry@gutov.dev>
> Cc: spwhitton@spwhitton.name, emacs-devel@gnu.org
> 
> On 20/09/2024 22:35, Dmitry Gutov wrote:
> >>> 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.
> 
> 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?

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

[Dmitry Gutov]

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?

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

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

[Eli Zaretskii]

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

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

[Dmitry Gutov]

On 21/09/2024 18:14, Eli Zaretskii wrote:

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

TeX yes. I'm also not sure about PostScript - but really because I still 
don't know how a function definition in that language looks, even after 
skimming through a manual.

Speaking of other extensions, isn't ".a" usually a compiled library 
rather than ASM source code? Also curious about ".t" for Scheme and 
".ml" for Lisp.

Not much else jumps out, but if somebody else has suggestions what to 
remove, we should probably do so (for the release branch). Basically, 
whatever extensions that might be not very common for a given language 
and could create false hits.

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

[Eli Zaretskii]

> Date: Sun, 22 Sep 2024 04:09:22 +0300
> Cc: spwhitton@spwhitton.name, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 21/09/2024 18:14, Eli Zaretskii wrote:
> 
> > 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?
> 
> TeX yes. I'm also not sure about PostScript - but really because I still 
> don't know how a function definition in that language looks, even after 
> skimming through a manual.
> 
> Speaking of other extensions, isn't ".a" usually a compiled library 
> rather than ASM source code? Also curious about ".t" for Scheme and 
> ".ml" for Lisp.

Fine, let's exclude all of these.  It still leaves quite a lot.

> Not much else jumps out, but if somebody else has suggestions what to 
> remove, we should probably do so (for the release branch). Basically, 
> whatever extensions that might be not very common for a given language 
> and could create false hits.

Agreed.

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

[Dmitry Gutov]

On 22/09/2024 08:19, Eli Zaretskii wrote:
>> Date: Sun, 22 Sep 2024 04:09:22 +0300
>> Cc: spwhitton@spwhitton.name, emacs-devel@gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>> On 21/09/2024 18:14, Eli Zaretskii wrote:
>>
>>> 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?
>>
>> TeX yes. I'm also not sure about PostScript - but really because I still
>> don't know how a function definition in that language looks, even after
>> skimming through a manual.
>>
>> Speaking of other extensions, isn't ".a" usually a compiled library
>> rather than ASM source code? Also curious about ".t" for Scheme and
>> ".ml" for Lisp.
> 
> Fine, let's exclude all of these.  It still leaves quite a lot.

Great! Here's the combined diff I plan to install:

- More extensions.
- case-fold-search bound to t, so extension matching is not case-sensitive.
- string-match-p for etags-regen-ignores entries, minor speed bump.
- *.a removed from the list, though it previously was in it (like 
discussed in this thread).
- *.def and *.inc also not added because I see .def being used for 
"module definition files", and .inc files sometimes have C-like 
contents, and sometimes SGML (with ASM in just a few examples). In the 
mozilla/gecko-dev checkout I tested, that is, to see how the change 
would affect indexing.

diff --git a/lisp/progmodes/etags-regen.el b/lisp/progmodes/etags-regen.el
index a8e67197070..11073c76ac6 100644
--- a/lisp/progmodes/etags-regen.el
+++ b/lisp/progmodes/etags-regen.el
@@ -118,9 +118,13 @@ etags-regen-regexp-alist
  ;; when it cannot determine the type of the file.
  ;; http://lists.gnu.org/archive/html/emacs-devel/2018-01/msg00323.html
  (defcustom etags-regen-file-extensions
-  '("rb" "js" "py" "pl" "pm" "el" "c" "cpp" "cc" "h" "hh" "hpp"
-    "java" "go" "cl" "lisp" "prolog" "php" "erl" "hrl"
-    "F" "f" "f90" "for" "cs" "a" "asm" "ads" "adb" "ada")
+  '("ads" "adb" "ada" "asm" "ins" "s" "sa" "S" "src"
+    "c" "h" "c++" "cc" "cpp" "cxx" "h++" "hh" "hpp" "hxx" "m" "pdb"
+    "cs" "hs" "erl" "hrl" "fth" "tok" "f" "f90" "for" "go"
+    "java" "cl" "clisp" "el" "lisp" "lsp" "lua" "lm" "p" "pas"
+    "pl" "pm" "php" "php3" "php4" "pc" "prolog" "py" "rb" "ru" "rbw"
+    "rs" "oak" "rkt" "sch" "scheme" "scm" "sm" "ss"
+    "y" "y++" "ym" "yxx" "yy")
    "Code file extensions for `etags-regen-mode'.

  File extensions to generate the tags for."
@@ -242,11 +246,12 @@ etags-regen--all-files
           (ir-start (1- (length root)))
           (ignores-regexps
            (mapcar #'etags-regen--ignore-regexp
-                  etags-regen-ignores)))
+                  etags-regen-ignores))
+         (case-fold-search t))
      (cl-delete-if
       (lambda (f) (or (not (string-match-p match-re f))
                  (string-match-p "/\\.#" f) ;Backup files.
-                (cl-some (lambda (ignore) (string-match ignore f ir-start))
+                (cl-some (lambda (ignore) (string-match-p ignore f 
ir-start))
                           ignores-regexps)))
       files)))


WDYT?

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

[Corwin Brust]

Hi Dmitry, all

On Sat, Sep 21, 2024 at 8:09 PM Dmitry Gutov <dmitry@gutov.dev> wrote:
>
> Speaking of other extensions, isn't ".a" usually a compiled library
> rather than ASM source code? Also curious about ".t" for Scheme and
> ".ml" for Lisp.
>

FWIW, for or me .t is Perl (test scripts written in -and usually for
testing- Perl)

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

[Eli Zaretskii]

> Date: Mon, 23 Sep 2024 19:57:09 +0300
> Cc: spwhitton@spwhitton.name, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> Great! Here's the combined diff I plan to install:
> 
> - More extensions.
> - case-fold-search bound to t, so extension matching is not case-sensitive.
> - string-match-p for etags-regen-ignores entries, minor speed bump.
> - *.a removed from the list, though it previously was in it (like 
> discussed in this thread).
> - *.def and *.inc also not added because I see .def being used for 
> "module definition files", and .inc files sometimes have C-like 
> contents, and sometimes SGML (with ASM in just a few examples). In the 
> mozilla/gecko-dev checkout I tested, that is, to see how the change 
> would affect indexing.

LGTM, thanks.

This is for emacs-30, right?

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

[Eli Zaretskii]

> From: Corwin Brust <corwin@bru.st>
> Date: Mon, 23 Sep 2024 12:07:59 -0500
> Cc: Eli Zaretskii <eliz@gnu.org>, spwhitton@spwhitton.name, emacs-devel@gnu.org
> 
> Hi Dmitry, all
> 
> On Sat, Sep 21, 2024 at 8:09 PM Dmitry Gutov <dmitry@gutov.dev> wrote:
> >
> > Speaking of other extensions, isn't ".a" usually a compiled library
> > rather than ASM source code? Also curious about ".t" for Scheme and
> > ".ml" for Lisp.
> >
> 
> FWIW, for or me .t is Perl (test scripts written in -and usually for
> testing- Perl)

It's a defcustom, so you can always adjust it to your personal needs
if the default value doesn't fit the bill.

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

[Dmitry Gutov]

On 23/09/2024 21:14, Eli Zaretskii wrote:
>> Date: Mon, 23 Sep 2024 19:57:09 +0300
>> Cc:spwhitton@spwhitton.name,emacs-devel@gnu.org
>> From: Dmitry Gutov<dmitry@gutov.dev>
>>
>> Great! Here's the combined diff I plan to install:
>>
>> - More extensions.
>> - case-fold-search bound to t, so extension matching is not case-sensitive.
>> - string-match-p for etags-regen-ignores entries, minor speed bump.
>> - *.a removed from the list, though it previously was in it (like
>> discussed in this thread).
>> - *.def and *.inc also not added because I see .def being used for
>> "module definition files", and .inc files sometimes have C-like
>> contents, and sometimes SGML (with ASM in just a few examples). In the
>> mozilla/gecko-dev checkout I tested, that is, to see how the change
>> would affect indexing.
> LGTM, thanks.
> 
> This is for emacs-30, right?

Yep.

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

[Dmitry Gutov]

On 23/09/2024 21:19, Eli Zaretskii wrote:
>> FWIW, for or me .t is Perl (test scripts written in -and usually for
>> testing- Perl)
> It's a defcustom, so you can always adjust it to your personal needs
> if the default value doesn't fit the bill.

I think the general theme here is we can/should be conservative in the 
default list.

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

[Dmitry Gutov]

On 23/09/2024 21:24, Dmitry Gutov wrote:
> On 23/09/2024 21:14, Eli Zaretskii wrote:
>>> Date: Mon, 23 Sep 2024 19:57:09 +0300
>>> Cc:spwhitton@spwhitton.name,emacs-devel@gnu.org
>>> From: Dmitry Gutov<dmitry@gutov.dev>
>>>
>>> Great! Here's the combined diff I plan to install:
>>>
>>> - More extensions.
>>> - case-fold-search bound to t, so extension matching is not case- 
>>> sensitive.
>>> - string-match-p for etags-regen-ignores entries, minor speed bump.
>>> - *.a removed from the list, though it previously was in it (like
>>> discussed in this thread).
>>> - *.def and *.inc also not added because I see .def being used for
>>> "module definition files", and .inc files sometimes have C-like
>>> contents, and sometimes SGML (with ASM in just a few examples). In the
>>> mozilla/gecko-dev checkout I tested, that is, to see how the change
>>> would affect indexing.
>> LGTM, thanks.
>>
>> This is for emacs-30, right?
> 
> Yep.

And pushed! Commit 32d0c8f6af5.

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

[Eli Zaretskii]

> Date: Mon, 23 Sep 2024 21:28:43 +0300
> Cc: spwhitton@spwhitton.name, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 23/09/2024 21:19, Eli Zaretskii wrote:
> >> FWIW, for or me .t is Perl (test scripts written in -and usually for
> >> testing- Perl)
> > It's a defcustom, so you can always adjust it to your personal needs
> > if the default value doesn't fit the bill.
> 
> I think the general theme here is we can/should be conservative in the 
> default list.

Agreed.

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

[Corwin Brust]

On Mon, Sep 23, 2024 at 1:28 PM Dmitry Gutov <dmitry@gutov.dev> wrote:
>
> I think the general theme here is we can/should be conservative in the
> default list.
>

Thank you! (I will build 32d0c8f6af52cd8db363456d817c3d214eea4c00
shortly and share back if I have any troubles).

Thank you also to Eli for the customization tip.  Will-co!