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: Sat, 30 Dec 2023 03:50:03 +0200 Message-ID: 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> <661f4951-cb0a-5257-63b0-efe71a0d217e@gutov.dev> 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="11081"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: 67687@debbugs.gnu.org, eskinjp@gmail.com To: Stefan Kangas , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Dec 30 02:51:17 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 1rJOVP-0002gV-N8 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Dec 2023 02:51:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rJOVD-0005NM-VP; Fri, 29 Dec 2023 20:51:04 -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 1rJOVC-0005Mr-73 for bug-gnu-emacs@gnu.org; Fri, 29 Dec 2023 20:51:02 -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 1rJOVB-00022y-Ve for bug-gnu-emacs@gnu.org; Fri, 29 Dec 2023 20:51:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rJOVC-0001GS-5L for bug-gnu-emacs@gnu.org; Fri, 29 Dec 2023 20:51: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: Sat, 30 Dec 2023 01:51: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.17039010164789 (code B ref 67687); Sat, 30 Dec 2023 01:51:02 +0000 Original-Received: (at 67687) by debbugs.gnu.org; 30 Dec 2023 01:50:16 +0000 Original-Received: from localhost ([127.0.0.1]:42647 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rJOUR-0001FB-Dt for submit@debbugs.gnu.org; Fri, 29 Dec 2023 20:50:15 -0500 Original-Received: from out2-smtp.messagingengine.com ([66.111.4.26]:52673) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rJOUP-0001Eu-2Q for 67687@debbugs.gnu.org; Fri, 29 Dec 2023 20:50:13 -0500 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 91BBA5C0217; Fri, 29 Dec 2023 20:50:06 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 29 Dec 2023 20:50:06 -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=1703901006; x=1703987406; bh=KuAD1Oqw/YK3hZhCQtcX61pMONb1i41G9952kXfPiqE=; b= J/WR8EkA9meikkMSVw5BIg8TrPHqlzbX26OkIb3F6/+Us9Nk2eiq3g7rYadVVA8Y MBCT/pAVBcjugwE5m27mPM9ADqtTf06ljtfX3RceTKyZ8eNRHq8Ap0GcbJiY1uU4 btjyVx6oFyxCsVjAaZaoSD6gzdM8kh8tGjV1YLMismgOpsWSsH+GcAyHgeO5kXvl iBV0eHjLOf56qVCKHpJpyNAbOJmyXuwrBQNFlUJMcc7EJrg2GjQF5Og28TLwvLU+ nkk9iRJOGaG1loh8TgPAoP6/tPPlekYN2nQDmmSUn1+cvgVBWj2Q6pzVaC90/2XN yB5AcTl//03PErnhkUD8/w== 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=1703901006; x= 1703987406; bh=KuAD1Oqw/YK3hZhCQtcX61pMONb1i41G9952kXfPiqE=; b=w TT8yYJNdUV6odXjfY9qm5X3rqRAEeC+7tiwpDJEfY3S8MOjQcEpw+dzcpGGhH8He IFs6NA6MR1VLRkWdLkePd6sxBeIdFxlmxw0tkrTt+QV00lc43r6nDoMwkVCKTz3i uu7erIK4za7lrFxzxM7N5t7Jd5bJ8ww2NEGczGqo8Klfzu5PKZINEBLpiU2lzKyZ qQ9cgRC8Qx12eC7Gz1v44C7rwj+VxrcrDDh3yj27aGogD2JEHLL+4YJpAWd1PDzz wFtDcRW1YYVWeKjKBTyIUfjvA8mLXazyArz2IB3YDVDmPoF0aEQUQUXrm2H+HK8H HydTIYPI/CEaJQVcojmCQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdefgedggeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepffeifedvleeukedtgfelieegudfgveekfeejveejffetffeuueeugefhveei uddvnecuffhomhgrihhnpehgnhhurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 29 Dec 2023 20:50:04 -0500 (EST) Content-Language: en-US In-Reply-To: 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:277050 Archived-At: On 30/12/2023 00:29, Stefan Kangas wrote: > Dmitry Gutov writes: > >> Fixed a typo in dir-locals and implemented better support for >> etags-regen-ignores (though with one omission). >> >> To me it looks good to check in now. > > Thanks for working on this long overdue feature. > > Do we really need a minor mode for this, or should it just be a > defcustom in etags? We have tons of minor modes for this or that > various minor feature, and the list in e.g. `C-h m' is really starting > to look really long, at least in my use. I wonder whether that is > really justified. As long as it's in a separate file, it should be easy to publish it to ELPA (as "core" package). Which is an option that's nice to have, even if not essential. Sometime later, when the features and implementation stabilize, we could merge the files, leaving the code in ELPA for older emacsen. Or something like that. >> diff --git a/.dir-locals.el b/.dir-locals.el >> index e087aa89cd1..ce7febca851 100644 >> --- a/.dir-locals.el >> +++ b/.dir-locals.el >> @@ -8,6 +8,12 @@ >> (vc-git-annotate-switches . "-w") >> (bug-reference-url-format . "https://debbugs.gnu.org/%s") >> (diff-add-log-use-relative-names . t) >> + (etags-regen-regexp-alist >> + . >> + ((("c" "objc") . >> + ("/[ \t]*DEFVAR_[A-Z_ \t(]+\"\\([^\"]+\\)\"/\\1/" >> + "/[ \t]*DEFVAR_[A-Z_ \t(]+\"[^\"]+\",[ \t]\\([A-Za-z0-9_]+\\)/\\1/")))) >> + (etags-regen-ignores . ("test/manual/etags/")) > > I'm not terribly familiar with how etags is implemented, so please > forgive me if some of these questions are naive. > > Is there any way around having to do so much manual setup to get this to > work? The above regexp is rather complex. > > And is the idea that users will customize this by themselves? Is it > feasible to shift most of that work to major mode authors [perhaps only > partially]? This is only necessary for language constructs not supported by etags OOtB. Such as our C macros which define Elisp functions and variables. These are the same regexps that we have in our Makefile. So this is a per-project thing, rather than per-language. Most users and projects shouldn't need it, or wouldn't need it right away. >> diff --git a/lisp/progmodes/etags-regen.el b/lisp/progmodes/etags-regen.el >> new file mode 100644 >> index 00000000000..88b730195c3 >> --- /dev/null >> +++ b/lisp/progmodes/etags-regen.el >> @@ -0,0 +1,411 @@ >> +;;; etags-regen.el --- Auto-(re)regenerating tags -*- lexical-binding: t -*- >> + >> +;; Copyright (C) 2021, 2023 Free Software Foundation, Inc. > > Using just 2021-2023 here is fine. Ok. >> +;;; Commentary: >> + >> +;; Simple automatic tags generation with updates on save. >> +;; >> +;; The goal of this mode is to provide a feature that should be >> +;; familiar to the users of certain lightweight programmer's editors, >> +;; such as Sublime Text. Which is "go to definition" with automatic >> +;; indexing, added in ST3 (released in 2017). > > This makes it sound like we're just copying others, when we could be > more confident. Emacs has had the described feature since before 2017. > I propose dropping all references to Sublime Text and reducing the above > to simply saying: But... it didn't? Otherwise you wouldn't have called it "long overdue", right? Anyway, I'm not married to the above text, it's just a description of how I'm thinking about the problem. But I would invite you and other to consider how the ST users take advantage of automatic indexing without having to be aware of how information is stored behind the scenes (tag files or not), when considering the sections of the manual touching on etags-regen-mode. > This library provides automatic indexing for Emacs "go to > definition" feature, the `xref-go-forward' command (bound to `M-.' > by default). Sure. We could also add some text that would distinguish it from the general notion of "automatic indexing", so that the users of Eglot, for example, don't consider it necessary to enable this mode. Even though they would also want indexing to remain automatic. >> +;; At the moment reindexing works off before/after-save-hook, but to >> +;; handle more complex changes (e.g. the user switching to another > > (We usually prefer "for example" to "e.g.".) No problem. Though searching across the codebase, the number of hits for these two options seems to be about the same (5K vs 4K).