|
From: | Dmitry Gutov |
Subject: | Re: Adding support for xref jumping to headers/interfaces |
Date: | Thu, 9 Mar 2023 18:53:42 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 |
On 09/03/2023 17:36, Eli Zaretskii wrote:
Date: Thu, 9 Mar 2023 15:04:09 +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>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?I'm not sure we'd need any UI. The command that works with declarations (say) would need to know that the default name of the tags file is TAGS.decl (say), and either ask the user or naybe even load that silently.
There is also the issue of having those files generated and saved to appropriate files. If I run 'etags -o TAGS', I might not expect that additional files will appear. Or existing ones -- overwritten.
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.Is it really that more complex?
The buffer state seems to be the least clear part of etags.el to me.I can easily imagine how to implement the feature the way I'm suggesting, and your way -- not so much.
OTOH, having those in a single file will need Xref to cope with multiple matches, something that currently we largely avoid. You'd have the same symbol mentioned once for declaration, another time for definition, perhaps yet another time for interface, etc.
We already support duplicates, don't we? E.g. definitions of the same method in different files, or even in the same file but in different classes (thus on different lines).
The main thing to decide is whether declarations will be included in the list of definitions. But that will just affect the behavior, not the ease of implementation.
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.My point was that we won't need dozen separate files. How we get to that conclusion, whether by analysis or by synthesis, is less important ;-)
If it's going to be a file per kind, then let's see how many we could support:
d, e, f, g, m, p, s, t, u, v, x. Not a dozen, but almost.Consider also this: someday we might want to stop supporting etags ourselves, as soon as we find an external tool which knows how to scan the same languages and outputs in the same format. At that point it will be an advantage if our output matches the information that some existing tool uses already. Like universal-ctags. Which could extend its TAGS output format to include our changes with little effort.
Or yet another approach: we switch to another file format right now which already supports the additional fields: ctags.
[Prev in Thread] | Current Thread | [Next in Thread] |