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

Previous Next

Full log

View this message in rfc822 format

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: bug#73484: 31.0.50; Abolishing etags-regen-file-extensions
Date: Sat, 05 Oct 2024 10:02:46 +0300

> Date: Sat, 5 Oct 2024 02:01:14 +0300
> Cc: spwhitton <at> spwhitton.name, 73484 <at> debbugs.gnu.org
> From: Dmitry Gutov <dmitry <at> gutov.dev>
> 
> On 04/10/2024 09:45, Eli Zaretskii wrote:
> 
> > So once again, I think this is a premature optimization.  The downside
> > of a larger TAGS will only have tangible effects in huge trees.
> 
> FWIW, TAGS for gecko-dev (Mozilla's repository which I have here for 
> testing) takes ~30 seconds to generate and ~400ms to find a definition 
> for the set of files to scan that I currently have set up. Both timings 
> seem quite impactful for user experience. I imagine some Emacs users 
> work at Mozilla, though that's only a guess.

Like I said: in huge trees this might matter.

But in any case, I don't understand the significance of the timings
you show: we are discussing the increase in processing time which will
be caused by adding files with no tags, which produce a single line in
TAGS.  Therefore the interesting figures are time differences in
processing some commands with and without those additional lines.  Are
the times you show above related to any of that?

> If someone were to provide a patch for etags with new functionality 
> (disabling fallbacks, at least), I could benchmark and come back with 
> numbers. And if experimental flags are available, with numbers for those 
> as well.

How hard is it to add to a live TAGS file fake lines which look like
this:

  ^L
  foo,0

(with random strings instead of "foo"), and then time some TAGS-using
commands with and without these additions?

> >> I would hope that project-find-regexp works well enough for that. Or
> >> 'M-x project-search' for the fans of the classic interface.
> > 
> > Maybe, but we do still want to keep tags-search, so the existence of
> > other commands don't invalidate my argument above.
> 
> In my mind, tags-search is for files that are code-related. Actual users 
> might differ, though.

The fact that we pass *.texi files to etags should already tell you
that this mental model is incomplete.  The fact that etags supports
HTML, TeX, and PostScript files (in addition to Texinfo) is another
evidence to that effect.  And that's even before we consider the
regexp feature, which could be used to tag anything in any kind of
file.

I agree that these use cases are relatively rare, but that doesn't
make them invalid or even unimportant.

> > If we want a separate optional behavior that prevents files with no
> > tags from being mentioned in TAGS, I'd argue that such an option
> > should affect all the scanned files, not just those whose language
> > could not be determined from their names.
> 
> I don't have a strong opinion here, just that it would depart from my 
> mental model mentioned above, of having all code-related files listed. 
> For example by missing some newly added .c file where no function 
> definitions have been added yet; 'M-x tags-search' would skip it.

This matches my impression that this option (which skips files with no
tags) should rarely if ever be used.

Previous Next

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