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: Mon, 27 Nov 2023 20:12:47 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

On 27/11/2023 19:46, João Távora wrote:

It's about "set of things where I usually want to pick only one and jump
to it" versus "set of things which I usually want to see the full list
of, which stays around".

You can say that "definition" is perhaps not an ideal term for the
former. But the distinction is useful, and if you have better naming
suggestions, go ahead.

Until now the only built-in commands which went through that dispatcher
were the variations of xref-find-definitions, so the name wasn't a problem.

This whole thing started because you used that misnaming of
existing things as a justification for misnaming new things.

And "implementations" are not definitions? Are "type definitions" not "definitions"?

What goes for declarations in a lot of cases will also be "definitions of some sort". E.g. in Java a method declaration is its abstract definition in the interface or parent class. There are also abstract method definitions in C++ and so on.

No, not pointless at all.  My main use case for this is to
first invoke the command on a given place of interest and _then_
ask myself what I want to see of that symbol. "All references",
"definitions", "declarations"?

The combined view, as implemented in the current
xref-find-all-definitions by default, will then just show references.

Not necessarily, it depends on the backend's.  But yes, it might.

How wouldn't it be?

Why would you want to also be able to reach "references" through that
interface anyway?

Why not? To avoid the noise of that categorization. To get to some
reference type not explicitly covered in those other categories.

To avoid the noise, you can just use an existing separate command.

Like I said, they are not "extra" because they will on most cases
include the kinds already shown by xref-find-definitions. I'm open to
other names, but please keep the intended semantics in mind (see above).

How bout "cross-reference", or simply xref?  There's a reason why your xref.el
which you maintain inherited that name from SLIME by whoever ported the UI
(Helmut it was, IIRC);-)  There's a lot of wisdom in that name.

That's the general term for all thingies Xref shows. The "xrefs" in the name "xref-show-xrefs-function" stands for pretty much that.

If you don't like "definitions" in "xref-show-definitions-function", then it would need to be a term that describes "special kind of cross-references". Probably referring to the kinds of locations those cross-references point to (which determines the optimal UI).



reply via email to

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