From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Francesco =?UTF-8?Q?Potort=C3=AC?= Newsgroups: gmane.emacs.bugs Subject: bug#73484: 31.0.50; Abolishing etags-regen-file-extensions Date: Sun, 29 Sep 2024 19:15:57 +0200 Organization: The GNU project Message-ID: <87ttdyfkj6.fsf@tucano.isti.cnr.it> 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> <86o7464tkc.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29500"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dmitry@gutov.dev, 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 Sun Sep 29 19:16:47 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 1suxXK-0007Vc-PT for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 29 Sep 2024 19:16:46 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1suxXA-0004Fz-3n; Sun, 29 Sep 2024 13:16:36 -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 1suxX5-00041x-RA for bug-gnu-emacs@gnu.org; Sun, 29 Sep 2024 13:16:32 -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 1suxX5-0003oS-H3 for bug-gnu-emacs@gnu.org; Sun, 29 Sep 2024 13:16:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:References:In-Reply-To:Date:From:To:Subject; bh=ppPWi3uiZI/ZmyBfN4GmtHeDRgwjTZIwuAJhmFV1yyg=; b=QQqgpP1FU58bdu/YVy0Vwi4onERW3M8nKqN3oUwE3UDW1c84Fu+F76S0NYCMoYGhWJOUtBCaIB//HoTVOQcH/8tl8hB5UYTl0oxUTApTXC9nhxXySpRsvt2uw4wEgwtaedjQIzMH3c5Go9yYUupS7Nz6tXdR2vXmKueBsx8Z/+uR0R3XemxlGIsOvdHgOjeuxKP0tta285y8bNGuBpjitOdmj2Ie6PyummSipEImW+j9XgSC3to6lycO/CfzeH71jwboPiS8RKd9Cx2u1qEeG5VRA93Ob4TjZlHFBu5AFyk/eNiPYBUAa15MBCZ47aPIlop7a4fFA5G7Jb5jwrEsVg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1suxXa-0007Ho-L5 for bug-gnu-emacs@gnu.org; Sun, 29 Sep 2024 13:17:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Francesco =?UTF-8?Q?Potort=C3=AC?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 29 Sep 2024 17:17: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.172763020027932 (code B ref 73484); Sun, 29 Sep 2024 17:17:02 +0000 Original-Received: (at 73484) by debbugs.gnu.org; 29 Sep 2024 17:16:40 +0000 Original-Received: from localhost ([127.0.0.1]:41321 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1suxXE-0007GS-8x for submit@debbugs.gnu.org; Sun, 29 Sep 2024 13:16:40 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:48278) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1suxXC-0007GD-M7 for 73484@debbugs.gnu.org; Sun, 29 Sep 2024 13:16:39 -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 1suxWa-0003nm-Vp; Sun, 29 Sep 2024 13:16:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:References:Subject:In-Reply-To:To:Date: From; bh=ppPWi3uiZI/ZmyBfN4GmtHeDRgwjTZIwuAJhmFV1yyg=; b=TiLXiK8hLtwQcneaiUX5 Cm5ufFKQJ4BRnjftiSGeZVh8WpzdENIhvhCBL8JPehCaQewdpCRnB06QnKZcKA+YuOook/YsPLEAB /HDcpc3CMlk4edjqgDJ9WbFE6rz4/XhSQJra24wasoDPlpZPuaTtlIH39D7zSUWTmt/rAhemG3iCg 0VBDzSiuPR2W3r7PhS3iDLDnsuhncekposbaGLgZBpldhkCAcuNW9swZM8ap3lsJROl1XZgvIJF6v dco0phcIGUOwI/5O4Hkqwkw/pVDuTQiFaW7rgBmCCskCBwvhGwGwlxkkVtiwzlIdpydLicraQBS4n +6lpZFUT+ndHIw==; In-Reply-To: <86o7464tkc.fsf@gnu.org> (eliz@gnu.org) X-fingerprint: 4B02 6187 5C03 D6B1 2E31 7666 09DF 2DC9 BE21 6115 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:292654 Archived-At: 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.