Re: Adding support for xref jumping to headers/interfaces

[Dmitry Gutov <dgutov@yandex.ru>]

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.