Re: Adding support for xref jumping to headers/interfaces

[Eli Zaretskii]

> 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.

> 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?

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.

> > 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.

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 ;-)