From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#73484: 31.0.50; Abolishing etags-regen-file-extensions Date: Thu, 3 Oct 2024 01:03:14 +0300 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20570"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: 73484@debbugs.gnu.org, spwhitton@spwhitton.name To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 03 00:04:25 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 1sw7SK-0005BT-Ar for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 03 Oct 2024 00:04:25 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sw7Rz-0002UJ-B3; Wed, 02 Oct 2024 18:04: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 1sw7Rx-0002U5-O1 for bug-gnu-emacs@gnu.org; Wed, 02 Oct 2024 18:04:02 -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 1sw7Rx-0004fY-Eu for bug-gnu-emacs@gnu.org; Wed, 02 Oct 2024 18:04:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=In-Reply-To:From:References:MIME-Version:Date:To:Subject; bh=34vEabMkoacxJn2PGn3WNwU+KpHLxHtCUCsV3dld5xc=; b=tbOQeTvEyXXh/OJMLT0h4IV09Dd4hh8Z19ajEYmcfOZomiPweluHPJbSACy9ZrP7u2+KncHTGzWEvjZSlaH2kdc3slwOVQij+4iNGMoO+81CQtN2rKmfecTSu+lbGnVBpF2JzoVqobbuc90I6RY93pyvlYqrzH0L4GR2uC1olqtUEpCF93NQ9Fd5wNltVgpVMBPDh97B+gyNP69VGTQKWnTVlktPj0o4au2YOR3EtjwfJcVENYeDYZKsAyUOUeNeJpwPNN52dMZcTnce+/jeu3IKd2n8ZgZr6hIwX6B9cIvhjQJ0aHlCjx/COEC2Ma++fOA9cIyuklR7TuVPIdIXSA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sw7Rx-0004GB-MT for bug-gnu-emacs@gnu.org; Wed, 02 Oct 2024 18:04:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Oct 2024 22:04:01 +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.172790660616324 (code B ref 73484); Wed, 02 Oct 2024 22:04:01 +0000 Original-Received: (at 73484) by debbugs.gnu.org; 2 Oct 2024 22:03:26 +0000 Original-Received: from localhost ([127.0.0.1]:59429 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sw7RO-0004FB-6x for submit@debbugs.gnu.org; Wed, 02 Oct 2024 18:03:26 -0400 Original-Received: from fhigh-a6-smtp.messagingengine.com ([103.168.172.157]:33449) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sw7RN-0004Ex-3E for 73484@debbugs.gnu.org; Wed, 02 Oct 2024 18:03:25 -0400 Original-Received: from phl-compute-10.internal (phl-compute-10.phl.internal [10.202.2.50]) by mailfhigh.phl.internal (Postfix) with ESMTP id EDAC81140162; Wed, 2 Oct 2024 18:03:18 -0400 (EDT) Original-Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-10.internal (MEProxy); Wed, 02 Oct 2024 18:03:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1727906598; x=1727992998; bh=34vEabMkoacxJn2PGn3WNwU+KpHLxHtCUCsV3dld5xc=; b= llrLFWXBlaPmzTXUeaYqc5PXX3q9UT8iq+b4rjqX3Z7rumXl9+4cGOaOqpCQfU/X qVtZKKKrcgi2KV3iGPNX6zS+3tBs+0oKLr0cbJSqwR6/o+GyGlDco3hehHIPlvlq 5wmLLp5pPWdnzUc68ulrJlAYpHEGBMG9bpYL0Vt2GH6l/u29PmBBCPci6FuYjGz5 Hd1KbLUURRiRB0AlnuvHY3KMMz9E3IGJ7755XKUEnxfkq+j4aV3rwCxSgdAfnHQd qUeKMBfddwhxRl6Sg75BVxgD5LPjgjyH85ZOQwMvRvx+nkLJl7nz0ot1HqvR4RmH huIxpmyiV8X6IA/UcW/mEA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1727906598; x= 1727992998; bh=34vEabMkoacxJn2PGn3WNwU+KpHLxHtCUCsV3dld5xc=; b=f cUs+Ve5I6ypCt2FXqN5YdhpssZflkuUreRmUTej019PXhNRQCru45Vf4cwGx1Fek TVHXbwuHLt42kerlM+a+w1f5OwxIei6TwtArsyRn9GI5T8xDKeOQFIjHSn3V53hI 4jirdu8Qkso5Zz9hL/XtLJ+eSJKNFducb1zNDcoKi7Ug/2SbfDLXC39ZGobYVeJz 82XJtGv0DqAAFTsilnV23QAXBE/6pSzvMGBxkNW31wmV4USxyj/ow/kGDu3ADEle 07BS2ElbdysfpR1tI8pt3WcnzoYoFsuGqKlykunK32RcXDefe/zdyU0DY/4TYS6/ oaIgHM4GOjEpdePNYGgDQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvddvtddgtdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdej necuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdrug gvvheqnecuggftrfgrthhtvghrnhepteduleejgeehtefgheegjeekueehvdevieekueef tddvtdevfefhvdevgedujeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthho peefpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrgh dprhgtphhtthhopehsphifhhhithhtohhnsehsphifhhhithhtohhnrdhnrghmvgdprhgt phhtthhopeejfeegkeegseguvggssghughhsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 2 Oct 2024 18:03:17 -0400 (EDT) Content-Language: en-US In-Reply-To: <865xqa1ggi.fsf@gnu.org> 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:292869 Archived-At: On 02/10/2024 21:56, Eli Zaretskii wrote: >> Date: Wed, 2 Oct 2024 21:00:58 +0300 >> Cc: spwhitton@spwhitton.name, 73484@debbugs.gnu.org >> From: Dmitry Gutov >> >> On 02/10/2024 14:28, Eli Zaretskii wrote: >>>> Date: Tue, 1 Oct 2024 02:19:17 +0300 >>>> Cc: spwhitton@spwhitton.name, 73484@debbugs.gnu.org >>>> From: Dmitry Gutov >>>> >>>> Just do nothing. >>> >>> Doing nothing means the file's name will not appear at all in TAGS. I >>> don't think that's TRT, since every file submitted to etags should be >>> mentioned in TAGS for the benefit of tags-search and similar features. >> >> Hmm, maybe another flag, then? >> >> Including many unrelated files would just bloat the tags file for little >> reason. And unlike manual generation, it's not like the user asked for >> all of them to be included. > > What do we tell to users of tags-search and its ilk? We can consider how most of such users' indexes look. See below. >>> So I currently tend to modify etags such that if no language was >>> detected by the file's name/extension, and this new no-fallbacks >>> option was specified, etags will behave as if given --language=none >>> (which also means that if any regexps were specified, they will be >>> processed correctly for such files). >> >> Any regexps for "all" files, right? > > The rules for regexps don't change: each regexp applies to the files > that follow it on the command line. This seems okay. >> ...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. 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. 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.