etags-regen-mode: handling extensionless files

etags-regen-mode: handling extensionless files

[Sean Whitton]

Hello Dmitry,

I'm working on a Perl project which has .pm files (which should be added
to etags-regen-file-extensions; I've written mail about that) but also
programs intended for execution, which have no file extension:
    <https://salsa.debian.org/dgit-team/dgit>.
E.g. 'dgit' and 'git-debrebase' in the project root.

On the one hand, it makes sense not to index these files because they're
programs not libraries, so their internal definitions won't ever be
referenced elsewhere.

On the other hand, it would be nice just to be able to use a simple
M-. to jump to definition, and not have to think about whether the
function is defined in the program or in a library.

Should we have some etags defcustom that allows specifying extra files
to index?  Or, as another idea, maybe etags could somehow include
looking at what imenu finds?  Might be too clever.

Let me know what you think about this use case.

-- 
Sean Whitton

Re: etags-regen-mode: handling extensionless files

[Dmitry Gutov]

Hi Sean,

On 20/09/2024 12:20, Sean Whitton wrote:

> I'm working on a Perl project which has .pm files (which should be added
> to etags-regen-file-extensions; I've written mail about that) but also
> programs intended for execution, which have no file extension:
>      <https://salsa.debian.org/dgit-team/dgit>.
> E.g. 'dgit' and 'git-debrebase' in the project root.
> 
> On the one hand, it makes sense not to index these files because they're
> programs not libraries, so their internal definitions won't ever be
> referenced elsewhere.

They're probably referenced internally though, at least once.

> On the other hand, it would be nice just to be able to use a simple
> M-. to jump to definition, and not have to think about whether the
> function is defined in the program or in a library.
> 
> Should we have some etags defcustom that allows specifying extra files
> to index?  Or, as another idea, maybe etags could somehow include
> looking at what imenu finds?  Might be too clever.

I guess we could add that extra option.

But see my other email regarding etags' hashbang detection.

Re: etags-regen-mode: handling extensionless files

[Sean Whitton]

Hello,

On Fri 20 Sep 2024 at 09:23pm +03, Dmitry Gutov wrote:

> Hi Sean,
>
> On 20/09/2024 12:20, Sean Whitton wrote:
>
>> I'm working on a Perl project which has .pm files (which should be added
>> to etags-regen-file-extensions; I've written mail about that) but also
>> programs intended for execution, which have no file extension:
>>      <https://salsa.debian.org/dgit-team/dgit>.
>> E.g. 'dgit' and 'git-debrebase' in the project root.
>> On the one hand, it makes sense not to index these files because they're
>> programs not libraries, so their internal definitions won't ever be
>> referenced elsewhere.
>
> They're probably referenced internally though, at least once.

Good point.

>> On the other hand, it would be nice just to be able to use a simple
>> M-. to jump to definition, and not have to think about whether the
>> function is defined in the program or in a library.
>> Should we have some etags defcustom that allows specifying extra files
>> to index?  Or, as another idea, maybe etags could somehow include
>> looking at what imenu finds?  Might be too clever.
>
> I guess we could add that extra option.
>
> But see my other email regarding etags' hashbang detection.

Hashbang detection would solve my problem elegantly.

Is my reading of the other thread correct that if we can fix the fortran
fallback then we can enable the hashbang detection?

-- 
Sean Whitton

Re: etags-regen-mode: handling extensionless files

[Dmitry Gutov]

On 22/09/2024 15:02, Sean Whitton wrote:

>> But see my other email regarding etags' hashbang detection.
> 
> Hashbang detection would solve my problem elegantly.
> 
> Is my reading of the other thread correct that if we can fix the fortran
> fallback then we can enable the hashbang detection?

Yep, I think so.

We would probably also discuss etags' auto-detection and its list of 
default extensions, during the next release's development.

Re: etags-regen-mode: handling extensionless files

[Sean Whitton]

Hello,

On Mon 23 Sep 2024 at 08:00pm +03, Dmitry Gutov wrote:

> On 22/09/2024 15:02, Sean Whitton wrote:
>
>>> But see my other email regarding etags' hashbang detection.
>> Hashbang detection would solve my problem elegantly.
>> Is my reading of the other thread correct that if we can fix the fortran
>> fallback then we can enable the hashbang detection?
>
> Yep, I think so.
>
> We would probably also discuss etags' auto-detection and its list of default
> extensions, during the next release's development.

Okay, cool!  Should we have a bug to track this?

-- 
Sean Whitton

Re: etags-regen-mode: handling extensionless files

[Dmitry Gutov]

On 25/09/2024 09:21, Sean Whitton wrote:
>> We would probably also discuss etags' auto-detection and its list of default
>> extensions, during the next release's development.
> Okay, cool!  Should we have a bug to track this?

Sure, please go ahead.

Re: etags-regen-mode: handling extensionless files

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: emacs-devel@gnu.org
> Date: Wed, 25 Sep 2024 07:21:58 +0100
> 
> Hello,
> 
> On Mon 23 Sep 2024 at 08:00pm +03, Dmitry Gutov wrote:
> 
> > On 22/09/2024 15:02, Sean Whitton wrote:
> >
> >>> But see my other email regarding etags' hashbang detection.
> >> Hashbang detection would solve my problem elegantly.
> >> Is my reading of the other thread correct that if we can fix the fortran
> >> fallback then we can enable the hashbang detection?
> >
> > Yep, I think so.
> >
> > We would probably also discuss etags' auto-detection and its list of default
> > extensions, during the next release's development.
> 
> Okay, cool!  Should we have a bug to track this?

We could, but adding an option to disable the Fortran fallback is so
easy that I hope someone will just do it...

Re: etags-regen-mode: handling extensionless files

[Francesco Potortì]

Eli Zaretskii <eliz@gnu.org>
>> > We would probably also discuss etags' auto-detection and its list of default
>> > extensions, during the next release's development.

Sean Whitton <spwhitton@spwhitton.name>
>> Okay, cool!  Should we have a bug to track this?
>
>We could, but adding an option to disable the Fortran fallback is so
>easy that I hope someone will just do it...

How about just going with the backward-incompatible change of disabling both fallbacks entirely?  In my opinion the whole fallback idea was already obsolete when I worked on it in 1993.

Today, I can't imagine a situation where it can be useful, that is, where you work on Fortran or C sources without an extension.

On the other hand, if you are working on thirty-years old sources, I argue you should use thirty-years old tools, rather than assuming that today's tool do the right thing on them.

-- 
fp

Re: etags-regen-mode: handling extensionless files

[Eli Zaretskii]

> From: Francesco Potortì <pot@gnu.org>
> Date: Wed, 25 Sep 2024 23:19:10 +0200
> Cc: emacs-devel@gnu.org,
> 	dgutov@yandex.ru,
> 	Sean Whitton <spwhitton@spwhitton.name>
> 
> Eli Zaretskii <eliz@gnu.org>
> >We could, but adding an option to disable the Fortran fallback is so
> >easy that I hope someone will just do it...
> 
> How about just going with the backward-incompatible change of disabling both fallbacks entirely?  In my opinion the whole fallback idea was already obsolete when I worked on it in 1993.

Since no one complained about it, and the only real use case is when
invoking 'etags' from a Lisp program, which can easily use a
non-standard option, I don't see a compelling reason for a
backward-incompatible change in behavior.  In some future version, we
can then flip the default and make the fallback disabled by default.

> Today, I can't imagine a situation where it can be useful, that is, where you work on Fortran or C sources without an extension.

My gray hair tells me that our ability to imagine such situations is
severely limited or biased, and we have enough evidence of this bias
to not trust our imagination in these matters anymore.

> On the other hand, if you are working on thirty-years old sources, I argue you should use thirty-years old tools, rather than assuming that today's tool do the right thing on them.

These arguments are usually not well taken, IME.  People want new
tools because they give them more functionality and performance, but
they do NOT want incompatibilities in the package.  IOW, everyone
likes to have the cake and eat it, too.