emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Adding support for xref jumping to headers/interfaces


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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]