Re: Adding support for xref jumping to headers/interfaces

[Dmitry Gutov <dmitry@gutov.dev>]

On 12/11/2023 20:59, João Távora wrote:

>> Dropping an implementation into master is one way to test out a
>> hypothesis, but it has inherent problems: the feedback comes late
>> anyway, and quite often we'd end up having to maintain half-bakes
>> features or unfortunate capabilities this way simply because they had
>> been added and time had passed.
> 
> Maybe.  Well Eglot has a fair enough audience, though not sure for
> this specific feature.  And I don't see any better alternatives if
> collecting feedback is what we want.  IOW, we shouldn't fall prey
> to "analysis-paralysis".

Hopefully not analysis paralysis. What we can do first, though, is 
iterate through a bunch of prototypes.

I was hoping to reach some sort of consensus before pushing the next 
one, but it's not really necessary for experimenting. So I'll just push 
the one I've been thinking of lately and see what everyone thinks.

>> Why contort? From where I'm standing,
>> declarations/implementations/typeDefinitions apply to almost any
>> object-oriented language (C++/Java/Ruby/Python/JS), and even some
>> functional ones.
> 
> What are "declarations" in JS, Java or Ruby and Python?

It's a pretty common term.

In Java, I'd be surprised if some interpreted it as something other than 
method definitions inside of an interface. And indeed: 
https://github.com/eclipse-jdtls/eclipse.jdt.ls/pull/2702

In JS, Mozilla's codebase actually had interface definitions, so a 
specialized backend could point to those. Some frontend frameworks had a 
thing similar to that.

No idea about Python's practices, but for Ruby there also are classes 
and mixins that have "abstract" methods. There are no syntactic 
annotations for that in the base language (you just throw a certain 
exception in the implementation), but the type-definition projects like 
Sorbet will likely change that.

The other two (implementations and typeDefinitions) make sense for the 
all of the above languages. Although "implementations" are of course 
only meningful to have when "declarations" exist.

> Perhaps
> nothing perhaps entirely different things. Also, there  are a lot of
> sub-kinds of declaration in C++.  Is a forward declaration of a
> type in C++ also a "declaration" here?

If the type is the entered identifier, why not?

I would first ask, are those definitions? Are they in the list returned 
by xref-find-definitions for the same input? If not, they might be 
useful to have in xref-find-declarations.

> What about a C++20 concept,
> is it a type definition?  No right?

I have no idea, but if it maps to the concept, and the users will find 
the binding in the common map using "M-' C-h", why not?

The only big downside is when xref-find-type-definitions already returns 
some different things, conceptually incompatible with the potential 
addition.

Or to look at it from another side, if xref-find-type-definitions is on 
"M-' t" in java-mode, would c++-mode prefer to have some other command 
on that bindings? If yes, would we want it to be arbitrarily incompatible?

> Or maybe, depends on who you ask
> some say it's a type for types.  Not to mention I think in Elisp we
> have at least 3 completely different kinds of "declaration": forward
> declarations, (declare ...) forms and defgeneric.  It's odd to mix
> them.

They can be returned together in xref-find-declarations (I would 
actually use that), and Elisp could have separate commands for more 
fine-grained navigation. Though the latter doesn't seem too much in 
demand, given they haven't materialized thus far.

> Anyway, this is LSP's taxonomy so it's LSP's problem (or rather,
> the problem of the poor servers that have to invent ways to shove
> things in these categories.  But not our problem by and large if we
> don't let  it spread any further than Eglot.  IMO Eglot is where
> LSP ends and Emacs starts.

The practice of shoving things into categories didn't appear from 
nowhere. Having common bindings and menu entries and easy transition 
between language modes is nice.

>> What's the alternative? To have many similar commands
>>
>>     ruby-find-implementation
>>     c++-find-implementations
>>     python-find-implementations
>>     js-find-implementations
> 
> Depends.  If you are using Eglot/LSP as a backend, you don't need to.
> Eglot already gives you the LSP trio.

ruby-mode doesn't choose an Xref backend. It just uses the configured 
one. Same for other modes in the above list.

> If you are using a non Eglot backend, then yes.  If you are using
> specific backend based on Eglot but with more servers, then yes too,
> but only for the extra types you support.

And for the rest? Unoccupied bindings? "undefined is not a function"? 
There be dragons?

Suppose a language doesn't support "declarations" in particular? Will it 
find a much better use for the corresponding binding in the prefix map?

>> that all do the same thing inside: call the Xref backend's "find
>> implementations" mechanism? It will be especially great to use if some
>> major mode authors bind that command to one key, and others to another.
> 
> I don't think it'll happen that often, and xref can define a good prefix
> map to use.  It's unlikely we or major modes would find keybinding space
> outside such a map anyway.

I'm saying it would be bad if java-mode binds 
java-find-interface-declarations to "M-' i" and c++-mode binds 
c++-find-forward-declarations to "M-' f", while they are more similar 
than different and could be both put on "M-' d".

>>> And Spencer even wanted to put cl-defgeneric in that bag, which I
>>> can fully understand, as cl-defgeneric can also be viewed as a
>>> declaration.  But its a completely different concept from those
>>> two.
>>
>> If Elisp doesn't have any other kind of declarations, what is the worry?
>> Let's put the ones it has.
> 
> But it does, at least for some understandings of "declaration".  And it
> could get even more.  A declaration is of course a reference to a thing
> that characterizes a part, but not the main part or totality of the thing.
> Besides the other two I mentioned already, any source code locus
> setting a property on a symbol could be viewed as that.  Are we prepared
> to handle this?  We could be.  If we are, do we really want to put this all
> in a one-size-fits-all "declarations" bag?

We are able to offer both the common "declarations" bag and separate 
lookup commands for finer searches. I would likely use the former.