GNU bug report logs -
#67687
Feature request: automatic tags management
Previous Next
Reported by: Jon Eskin <eskinjp <at> gmail.com>
Date: Thu, 7 Dec 2023 11:45:02 UTC
Severity: wishlist
Done: Dmitry Gutov <dmitry <at> gutov.dev>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
On 30/12/2023 00:29, Stefan Kangas wrote:
> Dmitry Gutov <dmitry <at> gutov.dev> 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).
This bug report was last modified 1 year and 142 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.