From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#73484: 31.0.50; Abolishing etags-regen-file-extensions Date: Thu, 03 Oct 2024 09:27:28 +0300 Message-ID: <86ttdtzoof.fsf@gnu.org> References: <87tteaznog.fsf@zephyr.silentflame.com> <8734lrrj4e.fsf@zephyr.silentflame.com> <87o74c1ce1.fsf@zephyr.silentflame.com> <87jzezzg87.fsf_-_@zephyr.silentflame.com> <37e4b3cd-6363-4f55-9921-92a1182679dc@gutov.dev> <86ttdy50ja.fsf@gnu.org> <75fe4289-da41-454d-ba92-22a92ea7002f@gutov.dev> <86frpe2186.fsf@gnu.org> <8e305b6d-8ca8-4437-990f-183ebc007d18@gutov.dev> <865xqa1ggi.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7235"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 73484@debbugs.gnu.org, spwhitton@spwhitton.name To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 03 08:28:19 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1swFJy-0001fe-KC for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 03 Oct 2024 08:28:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1swFJj-00031u-3x; Thu, 03 Oct 2024 02:28:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1swFJh-00031m-0k for bug-gnu-emacs@gnu.org; Thu, 03 Oct 2024 02:28:01 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1swFJg-0001xc-PI for bug-gnu-emacs@gnu.org; Thu, 03 Oct 2024 02:28:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=rXFiQsCQt+P51bIiP/JHWTxHXbSUOGNiAvL47zTXnMg=; b=NRiTWy86PrQt86+um0jqqO6mJSa+doaujuJrn7yBJTRmEeket4yXuoG838iCDvv3NlBsVlV9SlFTqPFJ7oweMyiUWVkaqL/2AyD1AnvsudlEgly8slFBeJ6uZiA7+dkkbF3EeVpB3gVSUrRLw6+fR/S6JmdyzEWEFNis1Zrlfhkh6qOEeBGbMVUs23ouX+S3tJoElJptXTgY2otf7IHQE3p8+0v8fCA9OCmvHdOuslAG36dPP2LCjEU2ZDCcITDgA79CYpEVEAZvXlqoP4Clqc5KPZFCL8Uq7asvG+1YXEY87Pz8KrNI1gIVeO8eOavLrbSsJSnXqfwqRVcCK0VMfA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1swFJi-0006wS-1j for bug-gnu-emacs@gnu.org; Thu, 03 Oct 2024 02:28:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Oct 2024 06:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73484 X-GNU-PR-Package: emacs Original-Received: via spool by 73484-submit@debbugs.gnu.org id=B73484.172793687126661 (code B ref 73484); Thu, 03 Oct 2024 06:28:02 +0000 Original-Received: (at 73484) by debbugs.gnu.org; 3 Oct 2024 06:27:51 +0000 Original-Received: from localhost ([127.0.0.1]:59765 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1swFJW-0006vw-U3 for submit@debbugs.gnu.org; Thu, 03 Oct 2024 02:27:51 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:41260) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1swFJU-0006vQ-JX for 73484@debbugs.gnu.org; Thu, 03 Oct 2024 02:27:49 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1swFJN-0001vk-89; Thu, 03 Oct 2024 02:27:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=rXFiQsCQt+P51bIiP/JHWTxHXbSUOGNiAvL47zTXnMg=; b=RBHG2Fu9dzGS ZY96WWl2vgwDAWQP93hBQvGGaNUQyuHMozk4gZ5pZPIhQUuDLdYgSlbVX21dyYXB8L3+iD3XNFv4l dvOastgezcuNabtVpkmgv9uckPQMfKQCNNX0CVG//7BCghniuZrWeFK/RXD9+HrdqSpkClxosIVP0 Ghq+YCW/+apE4twvJF8ovYvn1cmDy2+M/PZYDsZCGe1hCMtVDqrngjjWzvWb+t4/FIezpEVfyXqe8 5S/ajVCoevyI0EhdB5VWcm//b7bMWSl5bGq+Sfp/s1H6tKvzAVAQxa+xAW850FqzRXHpKytoKhIub upa8wUVh/Z6l03yPrqoAXQ==; In-Reply-To: (message from Dmitry Gutov on Thu, 3 Oct 2024 01:03:14 +0300) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:292884 Archived-At: > Date: Thu, 3 Oct 2024 01:03:14 +0300 > Cc: spwhitton@spwhitton.name, 73484@debbugs.gnu.org > From: Dmitry Gutov > > >> ...but if there are no matches I'd prefer the files to be skipped. The > >> files detected as type 'none' anyway. > > > > I don't like this, and I think this is misguided. I also don't see > > any special problem with having lines that name files in TAGS, it > > isn't like the size of TAGS will grow significantly or its processing > > will be significantly slower. IOW, this sounds like a clear case of > > premature optimization. > > I could do some experiments, if you post preliminary support of that > flag, with "empty" files in TAGS and without. OK. > But here's how I'm looking at it: > > Imagine a straightforward C project, one that has .c files, .h, maybe > .y, and also a bunch of docs, build artefacts (some of them checked in), > and maybe other data files as well. Also README, ChangeLog, Makefile, > config.bat, some .txt files, many other files without extensions, etc. > > Previously, when building a TAGS file manually, a developer in such a > project specified a list of file globs by hand. One that would be > limited to .[ch] files, and maybe .y as well, but not all the files in > the directory. If they definitely do NOT want the other files to be present in TAGS, they can keep using those globs. Nothing will change in that case. > To use Emacs itself as an example, the 'tags' target in our own Makefile > only includes .[hc], .m, .cc, .el and (surprising to me) .texi files. > But not any of the others. The number of such files is ~3K, if I'm > counting correctly. > > The total number of all non-ignored files in our repo is ~5K. That's 2K > more files that would be present in the 'M-x tags-search' or 'M-x > list-tags' outputs, if an Emacs developer simply switches to using > etags-regen-mode, and etags-regen-mode drops the file extensions > whitelist, and etags keeps all passed files' names in its output. OTOH, if a file with a known extension has no taggable symbols, you still get its file name in TAGS. So omitting files whose language we could not recognize would be an incompatible change in behavior. The fact that in the scenario you describe above 2K more files will appear in tags-search is, from my POV, an argument _for_ including them, not against: we have no reason to assume that users don't want to search those files for some regexp, because regexps specified in tags-search don't necessarily have anything to do with the identifiers we tag. A valid case in point is to look up all references to some file when the file is deleted, or references to some version when the version is updated: we definitely want files like README and INSTALL to be included in the search.