Re: Adding support for xref jumping to headers/interfaces

[Dmitry Gutov <dgutov@yandex.ru>]

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.