|
From: | Dmitry Gutov |
Subject: | Re: Adding support for xref jumping to headers/interfaces |
Date: | Thu, 9 Mar 2023 19:37:02 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 |
On 09/03/2023 19:31, Eli Zaretskii wrote:
Date: Thu, 9 Mar 2023 18:53:42 +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> 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.That's not what I had in mind. I thought we'd run etags several times, as in etags --enums-only -o TAGS.enum etags --decls-only -o TAGS.decl etc.
Okay. That sounds like additional hassle for the users, though.
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?Only when there's no way around that, and we consider that unfortunate when it does happen.
Sure.But whether we will show duplicates to the user, in any scenario, shouldn't depend on how we store information (in multiple files or not), only on what we do with it.
[Prev in Thread] | Current Thread | [Next in Thread] |