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#43086: [PATCH] Allow tags backend to not query for TAGS file Date: Tue, 10 Sep 2024 02:32:46 +0300 Message-ID: <7a242101-0bbb-43f1-846f-9d2a8f9a3990@yandex.ru> References: <87k0xjue75.fsf@posteo.net> <87zfoog084.fsf@posteo.net> <86v7z8yojd.fsf@gnu.org> <864j6pvy8y.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="22326"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: philipk@posteo.net, 43086@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Sep 10 01:34:10 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 1snntZ-0005fL-Rr for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 10 Sep 2024 01:34:10 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1snntQ-0007Wc-Am; Mon, 09 Sep 2024 19:34:00 -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 1snntO-0007W7-4l for bug-gnu-emacs@gnu.org; Mon, 09 Sep 2024 19:33:58 -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 1snntN-0006yZ-Qr for bug-gnu-emacs@gnu.org; Mon, 09 Sep 2024 19:33:57 -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=Hr/rV3iVAJLWUpSu9A+Olb3u+YbOh30I8u8yfD3mXiU=; b=SHbWztbiagQz1wDNfsosRp9k3oSTi6QG2kVjQiDMCEU639FE3Ol3Mm2FjMt5Spum8wwcE3ylm3KEQ6yl+ueETA0zIxlwO2DnE4+4iX7Yt8CunZfo0/Sa+aK3p/1+F1bbpxXs3Pl7cgarQYSfQvutETbBXZJdHNeOxTXTtg2r4JupT1/dVsMzLn5JJbvjYUE/84TwSIqdRu7LhSCvon6060FbSjNcN3dvC2BQR0R05tvPSMNlpSmT2N3zicR7EPsETU6Ik+lB5Dn8jALhXcrjEHOEaR4VhZnfycazmTH6z+NaoDrpWNZosOx60A7vsT4QhNhzPXtUJsaHW/RC3ebVhw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1snntR-0003di-LR for bug-gnu-emacs@gnu.org; Mon, 09 Sep 2024 19:34: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: Mon, 09 Sep 2024 23:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43086 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 43086-submit@debbugs.gnu.org id=B43086.172592478413924 (code B ref 43086); Mon, 09 Sep 2024 23:34:01 +0000 Original-Received: (at 43086) by debbugs.gnu.org; 9 Sep 2024 23:33:04 +0000 Original-Received: from localhost ([127.0.0.1]:34366 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1snnsW-0003cU-2f for submit@debbugs.gnu.org; Mon, 09 Sep 2024 19:33:04 -0400 Original-Received: from forward500b.mail.yandex.net ([178.154.239.144]:47594) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1snnsS-0003c2-5h for 43086@debbugs.gnu.org; Mon, 09 Sep 2024 19:33:02 -0400 Original-Received: from mail-nwsmtp-smtp-production-main-31.sas.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-31.sas.yp-c.yandex.net [IPv6:2a02:6b8:c08:de2c:0:640:e39b:0]) by forward500b.mail.yandex.net (Yandex) with ESMTPS id 6776360DCC; Tue, 10 Sep 2024 02:32:53 +0300 (MSK) Original-Received: by mail-nwsmtp-smtp-production-main-31.sas.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id oWrhWi0s98c0-WEKARMVq; Tue, 10 Sep 2024 02:32:52 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1725924772; bh=Hr/rV3iVAJLWUpSu9A+Olb3u+YbOh30I8u8yfD3mXiU=; h=In-Reply-To:From:Subject:Message-ID:Cc:References:Date:To; b=bjEc3mX/cifzz+ykU7wdWp2MnJMiL/Iqbg1+UYSxweNnH6rZ4E5cJF6qLyg4KQrkc Dszm84vet97B4D6gX8uIOsEvLn5GvapQ4zgIuPdiKICfHIM4XRDScGu0xXwHBjkLBr N9Dpyl5cZXVOIItrbyDQxwrHAExMH1AacaEwlcDY= Authentication-Results: mail-nwsmtp-smtp-production-main-31.sas.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: from phl-compute-07.internal (phl-compute-07.phl.internal [10.202.2.47]) by mailfauth.phl.internal (Postfix) with ESMTP id 8C7E71200078; Mon, 9 Sep 2024 19:32:49 -0400 (EDT) Original-Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-07.internal (MEProxy); Mon, 09 Sep 2024 19:32:50 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudeikedgvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdej necuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegughhuthhovheshigrnhguvgigrd hruheqnecuggftrfgrthhtvghrnhepiefhjeeuveetffffvdefteffffekhfeuudejieeh heeiudelgfehgffffeduffdunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepughguhhtohhvodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhi thihqddufeeffeelleehhedvqddvleegjeejjeejiedqughguhhtohhvpeephigrnhguvg igrdhruhesfhgrshhtmhgrihhlrdgtohhmpdhnsggprhgtphhtthhopeefpdhmohguvgep shhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhope hphhhilhhiphhksehpohhsthgvohdrnhgvthdprhgtphhtthhopeegfedtkeeiseguvggs sghughhsrdhgnhhurd X-ME-Proxy: Feedback-ID: ib1d9465d:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 9 Sep 2024 19:32:48 -0400 (EDT) Content-Language: en-US In-Reply-To: <864j6pvy8y.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:291532 Archived-At: On 09/09/2024 14:54, Eli Zaretskii wrote: >> Date: Mon, 9 Sep 2024 03:29:05 +0300 >> Cc: philipk@posteo.net, 43086@debbugs.gnu.org >> From: Dmitry Gutov >> >> On 07/09/2024 09:18, Eli Zaretskii wrote: >> >>>> Maybe just like this? This makes Xref identifier completion not query >>>> for TAGS unless already loaded. In many cases that would be TRT, >>>> although `C-u M-.` seems to regress (seems like we *would* want to query >>>> eagerly there). >>> >>> I don't understand why the obvious way of asking the user whether they >>> would like to generate the tags table is not the solution here. What >>> did I miss? >> >> I don't know if it's obvious, given that the optimal scenario at the >> beginning of the report describes >> >> ... allow the backend to never query a TAGS file > > But what do you expect from a backend that depends on TAGS to do when > TAGS is not there? You yourself just noticed the regression. Why > would we want that? I'm thinking of the xref-find-references case - where the scanner doesn't depend on the tags table being available. Just the identifier completion step. Perhaps Philip had other some situations in mind, too. > AFAIU, the problem here is that the backend can avoid querying when > the TAGS file exists. But what do you expect it to do when it does > _not_ exist? > We have the regeneration feature now, so I suggested to > ask the user whether to regenerate the file, after which it could be > read without any further prompts. We have an existing way to enable etags-regen-mode. And it's a global mode, so it's not just an issue of using it that one time - the naive solution will make stay on until the end of the session. Also, if the tags file is not loaded, we're not quite sure whether the user wants an auto-generated file, or an existing one. >> As it is, we already have a hint of the user preference from the fact >> that they have visited a TAGS file already (or not), or enabled >> etags-regen-mode (or not). It's not ironclad, but we could rely on these >> indicators to decide. > > Then regenerate TAGS without asking, if you think it's reasonable. > But letting the backend continue without TAGS is not a reasonable > solution, IMO. How do you feel about etags-regen-mode being on by default in some next Emacs release? It shouldn't conflict with the manual invocations of 'M-x visit-tags-file' - and of course if any cases come up we'll work on fixing those.