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#67687: Feature request: automatic tags management Date: Sun, 31 Dec 2023 19:53:27 +0200 Message-ID: <95132856-65b0-4812-a124-52e0da674330@gutov.dev> References: <2f86b882-9ec1-f63f-d90b-5f8f7ae114f2@gutov.dev> <58D84A29-9A63-45BA-AD8B-B476CDC931A1@gmail.com> <812729c8-726f-d60e-2603-2d8e588929fd@gutov.dev> <835y0sgg12.fsf@gnu.org> <979cf9e0-4d08-4c39-b5c8-11b0bb8801b4@gutov.dev> <83v88e3moc.fsf@gnu.org> <835y0e2ui8.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="18973"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: 67687@debbugs.gnu.org, eskinjp@gmail.com, michael.albinus@gmx.de, stefankangas@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 31 18:54:23 2023 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 1rK00z-0004hc-Qw for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 31 Dec 2023 18:54:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rK00h-00024b-Ca; Sun, 31 Dec 2023 12:54:03 -0500 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 1rK00f-00024T-RA for bug-gnu-emacs@gnu.org; Sun, 31 Dec 2023 12:54:01 -0500 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 1rK00f-0004vI-Ig for bug-gnu-emacs@gnu.org; Sun, 31 Dec 2023 12:54:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rK00g-0003sD-FA for bug-gnu-emacs@gnu.org; Sun, 31 Dec 2023 12:54:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 31 Dec 2023 17:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67687 X-GNU-PR-Package: emacs Original-Received: via spool by 67687-submit@debbugs.gnu.org id=B67687.170404522114864 (code B ref 67687); Sun, 31 Dec 2023 17:54:02 +0000 Original-Received: (at 67687) by debbugs.gnu.org; 31 Dec 2023 17:53:41 +0000 Original-Received: from localhost ([127.0.0.1]:47010 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rK00L-0003re-3Q for submit@debbugs.gnu.org; Sun, 31 Dec 2023 12:53:41 -0500 Original-Received: from out1-smtp.messagingengine.com ([66.111.4.25]:34313) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rK00I-0003rP-W7 for 67687@debbugs.gnu.org; Sun, 31 Dec 2023 12:53:39 -0500 Original-Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 305BE5C019C; Sun, 31 Dec 2023 12:53:32 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 31 Dec 2023 12:53:32 -0500 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=1704045212; x=1704131612; bh=g1hHqxjQIVkndQguZY6HL91XuqNryUp1aG5Awuh20l8=; b= Y1KzcLTVYCuL2mgXs4UMqxDE36WyHBqn2CaK8RkHJHVZ7oIxZpHCYRPoI4Cp1dSU jJ9VwuqhalOdKsTNmVYUmwG8CeRW9mBKwWQYcIby4Jv3y+fTyCNQ3FEuoNK2ywoP PEltjZkq2y0De59RgrksHI+BXpbrytAb6UYAO5leXAggaNhKIEmTHzwTaqzX9Mmu RnIlO/iWMfqIUTxFC1IXpR1VAY5CbooXmv3XgpeOzX8/3AGKqwhOZkgibYkraB5c x2YTyiKbvHOhrvoi5ka0GN/El/LL8odDj/Bg+Vr44Kz9Nnotl+Cf/p+/mJvhM9Vt 2QthfF+A8ev0GwZ1FmEkYA== 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=1704045212; x= 1704131612; bh=g1hHqxjQIVkndQguZY6HL91XuqNryUp1aG5Awuh20l8=; b=Z TH4k3DesDZzB8o8H60Q4HN7muHVbawR9QrOxXLVhvTLugfq7WEzkDQ5eGqyrPJwy 29EXFjkP/4uyvsYOIUZXhOTgXsfuyFHg3PuxpWZ44RsrASNTuU9Tv/MxG8Lzcel+ LdTiEv+ri046HYonuZs8mcvW1E2cgRZvnIOoxXhf83FvwwehkV8oILV9ifpW2w4j nPTOKOsbxgNPikdYImAJ488sWgYx5bLFPOweM3zZOdsn/QU/m+9NiDSEcuyogK3a +pdRTeFZpqpe50siStSYqnhQqXAISkO5DxyRpvD699hwRn2StD51Mvz5QOfeFvBx Gia2VQ4PWScz5qOWK+BfQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdefkedgkeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedu jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 31 Dec 2023 12:53:30 -0500 (EST) Content-Language: en-US In-Reply-To: <835y0e2ui8.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:277153 Archived-At: On 31/12/2023 18:42, Eli Zaretskii wrote: >> Date: Sun, 31 Dec 2023 17:25:35 +0200 >> Cc: eskinjp@gmail.com, 67687@debbugs.gnu.org, michael.albinus@gmx.de >> From: Dmitry Gutov >> >> On 31/12/2023 08:34, Eli Zaretskii wrote: >>>> +Note that this feature disables itself if you have already manually >>>> +visited a tags table (with @kbd{M-x visit-tags-table}, or through an >>>> +explicit prompt triggered by some feature that requires tags). >>> This aspect is IMO somewhat problematic. I wasn't aware of it, and >>> now that I read this, I'm not sure it is correct and will meet user >>> expectations. >> >> I'm pretty sure you asked for it: that even when this mode is on, it >> shouldn't interfere with completion tables explicitly visited by the user. > > "Interfere" and "prevent automatic regeneration" is not the same. > > I think this probably warrants a separate defcustom: some people might > want such regeneration, even if the tags table was loaded manually, > others won't. And I think the default should be to regenerate them > regardless. Like mentioned previously, I think we'll get such an option sooner or later, but not in the first check-in. It merits an additional discussion, at least. >> And either way it seems like a prerequisite for enabling >> etags-regen-mode by default sometimes in the future. > > How so? The fact that I loaded TAGS doesn't necessarily mean I don't > want it updated when the sources change. Or what am I missing? a) We won't add new files to the index, because we (apparently) can't simply use the project's list of files -- there is no guarantee that it matches the fileset that the original author of the TAGS file had in mind. b) There is no way to pick up the --regex options used for generating the original TAGS, or any other options we don't know about. So if we were to just use the logic of regenerating tags for newly changed files, we would end up with a mix of tags in some files based on the set of --regex used in the past, and with tags for new files based on the configured set of --regex options. Either way, we get a poorly-defined behavior with edge cases that are likely to surprise the user at different points of time. So we might indeed grow such a capability, but it'll probably stay off by default.