unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#73484: 31.0.50; Abolishing etags-regen-file-extensions
       [not found]         ` <b8001a72-8fc9-4e4e-a2d7-5da94a92f250@yandex.ru>
@ 2024-09-25 19:27           ` Sean Whitton
  2024-09-25 22:30             ` Dmitry Gutov
  0 siblings, 1 reply; 7+ messages in thread
From: Sean Whitton @ 2024-09-25 19:27 UTC (permalink / raw)
  To: 73484

Hello,

On Wed 25 Sep 2024 at 02:41pm +03, Dmitry Gutov wrote:

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

We want to replace etags-regen-file-extensions with enabling etags's
hashbang detection support.  That requires disabling its Fortran
fallback.

-- 
Sean Whitton





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#73484: 31.0.50; Abolishing etags-regen-file-extensions
  2024-09-25 19:27           ` bug#73484: 31.0.50; Abolishing etags-regen-file-extensions Sean Whitton
@ 2024-09-25 22:30             ` Dmitry Gutov
  2024-09-26  7:43               ` Francesco Potortì
  2024-09-29  8:25               ` Eli Zaretskii
  0 siblings, 2 replies; 7+ messages in thread
From: Dmitry Gutov @ 2024-09-25 22:30 UTC (permalink / raw)
  To: Sean Whitton, 73484

Hi!

On 25/09/2024 22:27, Sean Whitton wrote:

> On Wed 25 Sep 2024 at 02:41pm +03, Dmitry Gutov wrote:
> 
>> 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?
> 
> We want to replace etags-regen-file-extensions with enabling etags's
> hashbang detection support.  That requires disabling its Fortran
> fallback.

Thanks, a fuller plan would look something like this:

- Implement the --no-fortran-fallback flag in etags. Or an environment 
variable, or etc. Use it conditionally in etags-regen-mode.
- Revisit the default lists of extensions that etags recognizes, keeping 
in mind the recent thread we talking this about in - e.g. *.a seems out 
of place for ASM (someone more familiar with assembly dialects please 
feel free to correctme).
- Add new possible value t to etags-regen-file-extensions, and switch 
the default to it.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#73484: 31.0.50; Abolishing etags-regen-file-extensions
  2024-09-25 22:30             ` Dmitry Gutov
@ 2024-09-26  7:43               ` Francesco Potortì
  2024-09-26 12:18                 ` Dmitry Gutov
  2024-09-29  8:25               ` Eli Zaretskii
  1 sibling, 1 reply; 7+ messages in thread
From: Francesco Potortì @ 2024-09-26  7:43 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: 73484, Sean Whitton

>- Implement the --no-fortran-fallback flag in etags. Or an environment 
>variable, or etc. Use it conditionally in etags-regen-mode.

If your purpose is to avoid Etags creating false tags on files whose language it cannot detect, you need to disable all fallbacks, rather than just Fortran.

Sorry if I got lost and missed something.

-- 
fp





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#73484: 31.0.50; Abolishing etags-regen-file-extensions
  2024-09-26  7:43               ` Francesco Potortì
@ 2024-09-26 12:18                 ` Dmitry Gutov
  0 siblings, 0 replies; 7+ messages in thread
From: Dmitry Gutov @ 2024-09-26 12:18 UTC (permalink / raw)
  To: Francesco Potortì; +Cc: 73484, Sean Whitton

On 26/09/2024 10:43, Francesco Potortì wrote:
>> - Implement the --no-fortran-fallback flag in etags. Or an environment
>> variable, or etc. Use it conditionally in etags-regen-mode.
> If your purpose is to avoid Etags creating false tags on files whose language it cannot detect, you need to disable all fallbacks, rather than just Fortran.

Yeah, sorry, I guess the next fallback is C?

We'll want to disable both, so the flag would be --no-fallbacks, I guess.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#73484: 31.0.50; Abolishing etags-regen-file-extensions
  2024-09-25 22:30             ` Dmitry Gutov
  2024-09-26  7:43               ` Francesco Potortì
@ 2024-09-29  8:25               ` Eli Zaretskii
  2024-09-29 10:56                 ` Eli Zaretskii
  1 sibling, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2024-09-29  8:25 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: 73484, spwhitton

> Date: Thu, 26 Sep 2024 01:30:55 +0300
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> > We want to replace etags-regen-file-extensions with enabling etags's
> > hashbang detection support.  That requires disabling its Fortran
> > fallback.
> 
> Thanks, a fuller plan would look something like this:
> 
> - Implement the --no-fortran-fallback flag in etags. Or an environment 
> variable, or etc. Use it conditionally in etags-regen-mode.
> - Revisit the default lists of extensions that etags recognizes, keeping 
> in mind the recent thread we talking this about in - e.g. *.a seems out 
> of place for ASM (someone more familiar with assembly dialects please 
> feel free to correctme).
> - Add new possible value t to etags-regen-file-extensions, and switch 
> the default to it.

I understand that we need to disable the Fortran and C fallbacks to
avoid false positives, but what do we want to do if the fallbacks are
disabled and no suitable language parser is found using the file name?
Just skip the file and do nothing? emit a warning? something else?

I also don't understand why enabling the etags' shebang detection
requires to disable the Fortran and C fallbacks: etags looks for
shebang _before_ it falls back to Fortran and C, so what am I missing?





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#73484: 31.0.50; Abolishing etags-regen-file-extensions
  2024-09-29  8:25               ` Eli Zaretskii
@ 2024-09-29 10:56                 ` Eli Zaretskii
  2024-09-29 17:15                   ` Francesco Potortì
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2024-09-29 10:56 UTC (permalink / raw)
  To: dmitry; +Cc: 73484, spwhitton

> Cc: 73484@debbugs.gnu.org, spwhitton@spwhitton.name
> Date: Sun, 29 Sep 2024 11:25:45 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> I understand that we need to disable the Fortran and C fallbacks to
> avoid false positives, but what do we want to do if the fallbacks are
> disabled and no suitable language parser is found using the file name?
> Just skip the file and do nothing? emit a warning? something else?

Wait a minute... we already have "--language=none", which means only
do regexp processing, if any.  If no regexps were specified, 'none'
produces a single entry for a file, stating just its name, like this:

  ^L
  foo,0

where ^L is a literal \f character.  Is the intent here to prevent
even that from being written to TAGS?  If not, then we don't need any
new command-line option; instead, etags-regen could simply pass the
"--language=none" option before each file with no extension, and be
done, no?

Or maybe this is "the missing link" between this and the shebang
processing?





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#73484: 31.0.50; Abolishing etags-regen-file-extensions
  2024-09-29 10:56                 ` Eli Zaretskii
@ 2024-09-29 17:15                   ` Francesco Potortì
  0 siblings, 0 replies; 7+ messages in thread
From: Francesco Potortì @ 2024-09-29 17:15 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: dmitry, 73484, spwhitton

Eli Zaretskii:
>> I understand that we need to disable the Fortran and C fallbacks to
>> avoid false positives, but what do we want to do if the fallbacks are
>> disabled and no suitable language parser is found using the file name?
>> Just skip the file and do nothing? emit a warning? something else?

Eli Zaretskii:
>Wait a minute... we already have "--language=none", which means only
>do regexp processing, if any.  If no regexps were specified, 'none'
>produces a single entry for a file, stating just its name, like this:
>
>  ^L
>  foo,0
>
>where ^L is a literal \f character.  Is the intent here to prevent
>even that from being written to TAGS?  If not, then we don't need any
>new command-line option; instead, etags-regen could simply pass the
>"--language=none" option before each file with no extension, and be
>done, no?
>
>Or maybe this is "the missing link" between this and the shebang
>processing?

If you set language=none for files whose extension is unknown to Etags, then you give up on shebang processing.  If you do not set language=none and Etags does not recognise any shebang, it defaults to Fortran.  If it does not find any Fortran tags, it defaults to C/C++.  When default processing happens on a file which is neither Fortran nor C/C++, it usually generates no tags, but may occasionally generate fake tags.

AFAIU, the problem is that there are use cases when you have to feed Etags with files that should generate no tags, yet the occasional fake tags are not tolerable.





^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2024-09-29 17:15 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <87tteaznog.fsf@zephyr.silentflame.com>
     [not found] ` <edab570c-b2fa-4162-9383-df5c8aaff251@yandex.ru>
     [not found]   ` <8734lrrj4e.fsf@zephyr.silentflame.com>
     [not found]     ` <ea10f340-9b46-4199-93fc-274c5e81ace4@yandex.ru>
     [not found]       ` <87o74c1ce1.fsf@zephyr.silentflame.com>
     [not found]         ` <b8001a72-8fc9-4e4e-a2d7-5da94a92f250@yandex.ru>
2024-09-25 19:27           ` bug#73484: 31.0.50; Abolishing etags-regen-file-extensions Sean Whitton
2024-09-25 22:30             ` Dmitry Gutov
2024-09-26  7:43               ` Francesco Potortì
2024-09-26 12:18                 ` Dmitry Gutov
2024-09-29  8:25               ` Eli Zaretskii
2024-09-29 10:56                 ` Eli Zaretskii
2024-09-29 17:15                   ` Francesco Potortì

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).