|
From: | Dmitry Gutov |
Subject: | Re: Adding support for xref jumping to headers/interfaces |
Date: | Thu, 9 Mar 2023 15:04:09 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 |
On 09/03/2023 08:13, Eli Zaretskii wrote:
Date: Wed, 8 Mar 2023 22:15:18 +0200 Cc: stephen_leake@stephe-leake.org, john@yates-sheets.org, rms@gnu.org, fgunbin@fastmail.fm, casouri@gmail.com, sbaugh@janestreet.com, emacs-devel@gnu.org, azeng@janestreet.com From: Dmitry Gutov <dgutov@yandex.ru> On 08/03/2023 21:49, Eli Zaretskii wrote:If all the rest are also okay with such a change, then yes, this obstacle is down.Hmm, tag-implicit-name-match-p uses the $ anchor in its regexp (line 1652), seemingly unnecessarily. That condition can break. I suppose that we could ensure to only produce explicit tags when kinds are added. Or add a new switch to etags which would add kinds, default to off. Then the new feature would be supported (by etags backend) only for users who made sure to generate that info.Maybe an easier way would be to have separate tags files for each supported category (e.g., one for declarations and prototypes, one for definitions, etc.). Then we don't need to change the format of the tags file, only make changes in etags, and instruct etags.el to load the relevant file as needed.
What would the user interface for loading the tags look like?Altering our format sounds much easier to me from that standpoint, and from the added complexity in managing the files/buffers containing indexes for different types.
The list of categories provided by universal-ctags is quite long, but I think we only need to support a small subset of that for our purposes, right? That would mean perhaps 3 or 4 separate tags files, which might not be unreasonable.
The granularity in that list seems useful to me, so I don't think we should try to merge the kinds into some large categories, if possible.
We might not support distinguishing between certain kinds from the outset (e.g. between enums and structs, or between macro and function definitions), and we probably don't support outright a number of kinds like goto labels, parameter definitions and local variables. That leaves more than 3-4 kinds remaining, though.
[Prev in Thread] | Current Thread | [Next in Thread] |