Re: Adding support for xref jumping to headers/interfaces

[Eli Zaretskii]

> Date: Wed, 8 Mar 2023 20:23:21 +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 16:58, Eli Zaretskii wrote:
> >> Date: Wed, 8 Mar 2023 00:41:49 +0200
> >> From: Dmitry Gutov<dgutov@yandex.ru>
> >> 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
> >>
> >> After 'sudo apt install universal-ctags', I can see this:
> >>
> >>     $ ctags --list-kinds=c
> >>     d  macro definitions
> >>     e  enumerators (values inside an enumeration)
> >>     f  function definitions
> >>     g  enumeration names
> >>     h  included header files
> >>     l  local variables [off]
> >>     m  struct, and union members
> >>     p  function prototypes [off]
> >>     s  structure names
> >>     t  typedefs
> >>     u  union names
> >>     v  variable definitions
> >>     x  external and forward variable declarations [off]
> >>     z  function parameters inside function or prototype definitions [off]
> >>     L  goto labels [off]
> >>     D  parameters inside macro definitions [off]
> >>
> >> That seems to mean that it can distinguish "function prototypes" and
> >> "forward variable declarations", although their scanning seems to be
> >> disabled by default (can be toggled via --kinds-c=+p+x).
> >>
> >> So I suppose the question here is how hard it would be to add to
> >> existing etags parsers something like that, and whether we can extend
> >> the TAGS format in a backward compatible way with this info.
> > How do you envision a backward-compatible extension of TAGS format to
> > support such flags?  AFAIK, TAGS doesn't distinguish between the tags
> > by their kind, it just records all of them, and leaves the semantics
> > to the program which reads them.  The current format of TAGS is
> > described in etc/ETAGS.EBNF, in case you didn't know.
> 
> etags-snarf-tag doesn't seem to call (line-end-position), at least not 
> in the latest version. So we can probably add
> 
>    DEL kind
> 
> to the end of both directtag and patterntag.
> 
> At least, if I just add "^?f" to the end of a random line, 
> (etags-snarf-tag) still returns the same value right now.

There's more than just etags-snarf-tag that know about the format of
the file.  If all the rest are also okay with such a change, then yes,
this obstacle is down.  The next one is to teach etags itself produce
those flags.