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 00:50:42 +0200 Message-ID: <75a55999-72b9-40dd-a1b7-5c272956fc4a@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> <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="21469"; 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 23:51:19 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 1rJiAn-0005O4-MU for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Dec 2023 23:51:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rJiAb-00014R-1Y; Sat, 30 Dec 2023 17:51:05 -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 1rJiAY-000143-Ff for bug-gnu-emacs@gnu.org; Sat, 30 Dec 2023 17: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 1rJiAY-0001mN-7B for bug-gnu-emacs@gnu.org; Sat, 30 Dec 2023 17:51:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rJiAY-0001ZF-E7 for bug-gnu-emacs@gnu.org; Sat, 30 Dec 2023 17: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 22: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.17039766586012 (code B ref 67687); Sat, 30 Dec 2023 22:51:02 +0000 Original-Received: (at 67687) by debbugs.gnu.org; 30 Dec 2023 22:50:58 +0000 Original-Received: from localhost ([127.0.0.1]:45193 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rJiAT-0001Yt-GT for submit@debbugs.gnu.org; Sat, 30 Dec 2023 17:50:57 -0500 Original-Received: from out3-smtp.messagingengine.com ([66.111.4.27]:57471) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rJiAP-0001Ye-8V for 67687@debbugs.gnu.org; Sat, 30 Dec 2023 17:50:55 -0500 Original-Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 5DE875C015C; Sat, 30 Dec 2023 17:50:46 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sat, 30 Dec 2023 17:50:46 -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=1703976646; x=1704063046; bh=fdlzUlNbNYQ7XJKfkjmVuDB2BNwYXyI5NzZDop4UTgU=; b= sDX87WluTFiGxsnH+VwdstZ0Rm2NsboXlvHy0yiwE3045J+/mh403OC7/2IylItD 8pwzSoIFcYzSJAOHUb6lLycFNmqA0eMn2bE69VexBpG5vZOUlzy9ALP1N5SXaIKd mkGJS7EBFg5dxYSUWcEFe1E/r5STSUnINXxg1ZA/IQulHdJJdpYhHENaT9a+5qw7 VH05B0QxkXUJu1tZK5sEP22lFYR0zL1dlu8DyQ5Zfn1Pgb1toTrY251qXwNePgub CnpRMDbBe2Zn3gCC+PUAKx0lWvCFyH+kxgW3g/1VscMA8XSVVNjCom8kEZqarOC5 xe0YrfLf3gwlx2RFkCijMA== 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=1703976646; x= 1704063046; bh=fdlzUlNbNYQ7XJKfkjmVuDB2BNwYXyI5NzZDop4UTgU=; b=A 2jPtNNkb2e3MuCUlnTlD/TKIBOwDQ6N1E9CvW8yxfu+B5XurApBmwcySP9ufo7uA l9SaHOckj+OhwJYtzvB1rRdsOOSwhqmLZfZ0d7ZL7MJl2btWwnEvOwi6xWbRvnO3 VwoLY6SYzH0bk0iz+51J6tYse4NYU57hRlnQArtxAN7Rgxj5kAt5GZP+1k2w0b9Z xhICzxsaZObUXe53FthZs2Snxgmr9K8KYK5IuWGV20MrrBqrg6IX8BIHp7BuLnaa SdqXDi0S7ISrlbkxzejWDC9NX4j0muJJ4fsJ4zdTHTlJeJGCvc5Lkf8G4Evta2ei vwRGEoNmZbl5WisYz4fHQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdefiedgtdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedu jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 30 Dec 2023 17:50:45 -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:277106 Archived-At: On 30/12/2023 22:31, Stefan Kangas wrote: >> 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. > > Ah, that makes more sense to me now. Thank you. > > Would it be helpful to put that explanation in the .dir-locals.el file > itself? .dir-locals.el already usually hosts per-project settings. And most users of this feature probably aren't going to read Emacs's one. I've added another sentence to the docstring, let's see if it helps. >>>> +;;; 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? > > Uhm, yeah, that could have been more clear. I must have hatched a key > sentence when editing, or something. Please let me try again. > > The proposed text seemed to open up for the misunderstanding that "go to > definition" is a new feature, that Sublime text introduced in 2017 and > Emacs will now get in version 30.1. You might be right. The file/feature only contains the automatic indexing part, though. > I think we should clarify that the new feature is only "automatic > indexing". Furthermore, doing things for the user in the background is > hardly revolutionary enough that we need to give Sublime text the credit > for the invention, or anything like that. It's rather mundane these > days, as far as features go. Users have learned to expect it. > > This is what makes the feature long overdue. Yeah, it's hardly an innovation, more like in the "why don't we have this yet" department. But while automatic indexing has been around for a while, having it OOtB in lightweight editors wasn't commonplace. So as I recall it for ST3 (first beta in 2013, release in 2017) it was a meaningful step forward. The complex IDEs already had this for a long time, of course (but each was more specialized, and worked with a smaller number of languages). >> 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. > > Indeed, the possible confusion with eglot could bear some documenting. > Perhaps we should add a new paragraph to the commentary explaining how > this feature will (or will not) interact with Eglot. Suggestions welcome. I'm not sure how to phrase that without mentioning etags, tags files, and xref backends (in general and the names of specific ones). >>>> +;; 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). > > Search for "abbreviations" in (info "(elisp) Documentation Tips"). > > But when we made that addition, we didn't bother changing all existing > documentation. IIRC, most people in that discussion preferred a more > gradual approach. All right, I've replaced the two "e.g."'s in user-facing text.