GNU bug report logs - #73484
31.0.50; Abolishing etags-regen-file-extensions

Previous Next

Full log

Message #29 received at 73484 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 73484 <at> debbugs.gnu.org, spwhitton <at> spwhitton.name
Subject: Re: bug#73484: 31.0.50; Abolishing etags-regen-file-extensions
Date: Tue, 01 Oct 2024 18:00:36 +0300

> Date: Tue, 1 Oct 2024 02:19:17 +0300
> Cc: spwhitton <at> spwhitton.name, 73484 <at> debbugs.gnu.org
> From: Dmitry Gutov <dmitry <at> gutov.dev>
> 
> On 29/09/2024 11:25, Eli Zaretskii wrote:
> > 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?
> 
> Just do nothing. We'd really want to delegate language detection to 
> etags rather than doing it inside Elisp - the latter is slower and 
> ultimately more limited. But for that etags needs to have a reliable 
> detection logic, one without too many false positives (and IME false 
> positives here are worse than false negatives, because scanning too much 
> can often mean both wrong tags and long scans, and a completion table 
> that gets too large because of bogus tags).

I'm not sure I understand: if you worry about performance, then
disabling fallbacks will not eliminate all of the cases where etags
scans the entire file or at least some of its portions.

Can you explain to me again what exactly is the problem with the
fallbacks in the context of etags-regen?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.