ReferenceProvider API

Hi!

For long there's a (closed) API to the ReferenceProvider subsystem which
is used extensively by many plugins. Right now we're thinking about
opening the API and because of that we have several questions to our
community:

1. We think that current API doesn't look good and that's why we're
thinking about creating new system and deprecating the old one. Does it
sound good for you?

2. Do you have any wishes concerning the features of new API which are
not present in current API?

3. Do you have any specific comments about the existing API? Do you know
how to make it better/easier to use/debug?

We'd like to listen to all of you carefully before starting any serious
work on this.

9 comments

Hello Mike,

I have not used the current API extensively, but it seems that the current
ReferenceProvider is an aspect of "completion" in general.

Again, based on limited use, I would wish for:
1) Better support for reference completion customization (all the current
LookupItem/LookupValue* stuff)
2) In the context of custom languages: clear API for completion for custom
keywords, smart completion, classname completion

Hope this helps,
-tt


0

One feature I miss very much:

http://www.jetbrains.net/jira/browse/IDEA-6410 Need ability to override IDEA's builtin ReferenceProviders

It should be possible to extend/disable existing/loaded RefProviders, so a plugin is able to offer "better" versions than the ones provided by IDEA itself.

0

I think the current API is okay. An addition to the PsiViewer tool, which would highlight all references in the current editor, and show information about them, would be great for debugging.

I don't like that completion is tied to reference providers, because sometimes something resolves to a local variable, but you also want to provide completions for a method, so the link between PsiElement type and completion breaks down.

I also think there needs to be a way to specify an "auxillary" reference, so it doesn't show up in Ctrl+Click (as a PolyvariantReference), but is still used for Find Usages. This would be useful for adding references to Java code for example.

0

Hi Mike,

the parts of the API I use seem quite straightforward. I don't have any big complaints or
problems with it. Why do you think it doesn't look good?

One particular thing a new API should include is not only reference providers, but also
frequently used reference implementations, such as file/directory references (with
configurable base-paths).

Since references in IDEA are closely related to completion, I think this area of the API
should be opened as well. It might even be more important to open the whole completion
subsystem than just the rather simple ReferenceProviders.

Do you already have some plans or ideas how the API would look like? It might be easier to
get the discussion going if there's a very first draft.

Sascha

0

+1 on opening plain Completion-API as well

and provide some hooks to "add" CompletionVariants to already existing Languages/FileTypes

0

I have a reference provider related question. I need to implement the following:
1. Some html tag has custom attributes, and IDE should not highlight them as custom.
Should I register an extended XmlElementDescriptor instance for this, or some metadata instance? Is there another way?
2. Navigation from html attribute name to the java property. Related to the p.1

Seems, I can add custom tag attributes if register the XmlNsDescriptor instance through MetaRegistry.

0

Hello, Sascha,

Indeed completion API would relieve the pain of custom languages plugins writers. (I'm starting feeling sick when I think we'll need to use closed API for this in Scala plugin). However opening this is by far more difficult than just opening reference providers.
Current API is way too complicated and requires lots of refactoring. As a first step it would be very instructory to know what aspects of completion (e.g. what aspects of presentation/handing item insertion) do plugin writers want to customize.

0

Hello Eugene,

Well, what should the completion API provide? I think everything that is used by the JavaScript plugin (the LookupValueWith* interfaces, CompletionVariant, InsertHandler, etc.) would be a good start. And probably some other stuff that has been discussed here in the forums (sorry, I don't remember what exactly).

It would also be good to have a proper way to hook into the other completion actions, especially Smart Completion.

Sascha

0

Hello, Eugene

When i was writing a custom language plugin i remember there was a little problem to find out about what to return from getVariants method. The "official" guide said to return PsiElements but that's not what was going on in Java or JavaScript. I think that more information about this topic would be of help and the Object[] return type is confusing.

The bigger problem was with completion that pops up automatically. This one i did not solve. I think that clearing this aspect would also be of great help to custom languages.

0

Please sign in to leave a comment.