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: Wed, 2 Oct 2024 01:01:23 +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> <86a5fn3m23.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="29764"; 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 Wed Oct 02 00:02:36 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 1svkx0-0007Zk-VT for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 02 Oct 2024 00:02:35 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1svkwc-0003lQ-KB; Tue, 01 Oct 2024 18:02:10 -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 1svkwU-0003l1-Vg for bug-gnu-emacs@gnu.org; Tue, 01 Oct 2024 18:02:03 -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 1svkwU-0001AG-AR for bug-gnu-emacs@gnu.org; Tue, 01 Oct 2024 18:02:02 -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=QhGe4Rc7rkIpT/PtT6JUOyKK/zxDU2uhNWfKxEQZYnM=; b=eTNT32aqMdSfh2bmx2c4JhHh8CyUuponz9wkA3zBBqdw35O95hKNrjqwERomdPuq19+4j5/zibDiLBP7gtYEk9cOuV5y7L3OplKJto9embzR5rNdRpx68gXtdWjcB1+BOUYuznlHvCN9M417AnhDV3HPZTuuIWi4qq2l750HUfaEwInlB83onWwF+c+PvIRxQ4HUp3VVWvmVwJ4jh7Uux7dkBQXOT5SbHAYrZ2af0KAcgJRz3unXBlIWaHAe87KT7iKmJMnYq25DVGa6zAoIfN8BnMvH3GUyVSoH0EWkY+tTt2tc2u45wffDaPBSFErulE1UKmvnuZK4CZFHQv6tsg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1svkwT-00055f-Rp for bug-gnu-emacs@gnu.org; Tue, 01 Oct 2024 18:02: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: Tue, 01 Oct 2024 22:02: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.172782009419554 (code B ref 73484); Tue, 01 Oct 2024 22:02:01 +0000 Original-Received: (at 73484) by debbugs.gnu.org; 1 Oct 2024 22:01:34 +0000 Original-Received: from localhost ([127.0.0.1]:53938 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svkw2-00055J-2K for submit@debbugs.gnu.org; Tue, 01 Oct 2024 18:01:34 -0400 Original-Received: from fhigh-a7-smtp.messagingengine.com ([103.168.172.158]:42023) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svkvz-00055A-Qv for 73484@debbugs.gnu.org; Tue, 01 Oct 2024 18:01:32 -0400 Original-Received: from phl-compute-01.internal (phl-compute-01.phl.internal [10.202.2.41]) by mailfhigh.phl.internal (Postfix) with ESMTP id 017AA1140521; Tue, 1 Oct 2024 18:01:27 -0400 (EDT) Original-Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-01.internal (MEProxy); Tue, 01 Oct 2024 18:01:27 -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=1727820086; x=1727906486; bh=QhGe4Rc7rkIpT/PtT6JUOyKK/zxDU2uhNWfKxEQZYnM=; b= SsvKF2rvHO9keQl0cnBQGbKPsAuYrk1LWAi5mk7jls7akRMo8y4+n7TEmxCO0gwq bmETVByz0nRnmAUFeoP0m6vZ/Q/e75Ad4n0iGVbhDNKZUnKoXqJOabajymqNptjZ Awnqno96hCnvDqU6fqs4BuJquArStyyhBD/OL2+8Ruy6MBeCq5HQ80s+lh2awG9V i/wBjr4Myhc5VKD576LnQiHsockfKe6hBQoiEUgKEdn3w6N5He+nlhH0NKKMNNAD uiTe999wGYyO/xKH+K/vA/1+uzIMc/NmP+U5+b4aLmTi/y4B63ycqaaVAcwnEWKd Tkwag9KFc+cmmgOmTR54uQ== 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=1727820086; x= 1727906486; bh=QhGe4Rc7rkIpT/PtT6JUOyKK/zxDU2uhNWfKxEQZYnM=; b=L nZVQxmTlep68JbJFAFzLvlVcodq5URLNzWjT140HTa4YzGZsTqrjsXOycJIHSG1Q fsf+evA1yW/y5d7DyOhhXZXwFnjnmXJOMJjW34GYz9xk74OU/P7BCov2vt13a2iu KO67Qcoe6aMylka2G6DO7JlWCkBCN7n6Xf2SlHDejqIobipfDtSYbl/QntwceFti BrPQrDZD5YTCFj3nJdo6PNUEPv3l8UGwkM19EaVtriB2NS3xmOs4PltYPq9xgejC VkhCb3n2XCSh6za9HjMTqh2xJk4QMjoWMT08T0Pj1pJUoGu1Tr+qAAEvBAS+2HqB BLeAbmOOd4GeYPZNz677Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvddukedgtdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdej necuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdrug gvvheqnecuggftrfgrthhtvghrnhepffeifedvleeukedtgfelieegudfgveekfeejveej ffetffeuueeugefhveeiuddvnecuffhomhgrihhnpehgnhhurdhorhhgnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhht ohhvrdguvghvpdhnsggprhgtphhtthhopeefpdhmohguvgepshhmthhpohhuthdprhgtph htthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopehsphifhhhithhtohhnsehs phifhhhithhtohhnrdhnrghmvgdprhgtphhtthhopeejfeegkeegseguvggssghughhsrd hgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 1 Oct 2024 18:01:25 -0400 (EDT) Content-Language: en-US In-Reply-To: <86a5fn3m23.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:292800 Archived-At: On 01/10/2024 18:00, Eli Zaretskii wrote: >> 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. etags's scanning should still be faster than doing it in Lisp, or the subsequent calls to tags-completion-table or etags--xref-find-definitions. Further, the last function would repeatedly search through the tags file, so it's important to keep tags' scanner accuracy high: without incorrectly recognized files, and without wrong index entries. > Can you explain to me again what exactly is the problem with the > fallbacks in the context of etags-regen? We've talked about this before, here's my previous reply: https://lists.gnu.org/archive/html/emacs-devel/2018-01/msg00387.html I don't have the same experiment at hand, but the past me seems to be saying that scanning files incorrectly can also make the whole scan take longer, considerably. And make the resulting file bigger, which makes its parsing from Emacs slower as well, and so on.