Priority/Order of ItemsProviders on the process of CodeCompletion

[Dennis Albrecht]

Hey guys,

Could someone provide me any information about how to configure the priority of some ItemsProvider? I already looked at the super-classes of CSharpItemsProviderBasic (the abstract ItemsProvider that I use) and in the JetBrains Documentation of how to extend the process of CodeCompletion but both wasn't successful. And Google isn't suitable for this question (or I used the wrong keywords for my search).

Greets Dennis

[Sven Amann]

It's a little difficult to investigate on this without a VS machine available... I didn't find the respective method in the classes I thought to have them. I'm quite sure that there was some way to specify a provider priority. I seem to remember that I found this together with Uli, some time ago. Maybe he can help you out?

Best,

Sven

--
You received this message because you are subscribed to the Google Groups "kave-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kave-dev+u...@googlegroups.com.
To post to this group, send email to kave...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kave-dev/770bfd6b-bd71-485c-a44a-734fb9831aef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sebastian Proksch]

To sum up the offline discussion... you did not find a way to change the priority, but added a listener that is informed about future additions of other providers.

Could you provide some technical details about how exactly this was achieved?

best

Sebastian

[Sven Amann]

Our proposal provider overrides the AddLookupItems method of CSharpItemsProviderBasic, which receives a GroupedItemsCollector as one of its arguments. Through this collector, providers add their proposals to the code completion. The collector has a list (Items) of all previously added proposals and an event called ItemAdd, which is raised whenever some provider adds another proposal. We simply process the list of every existing proposal on the spot and then listen for new proposals to arrive. Caveat: The proposals we add ourselves need to be filtered from processing, to prevent an endless loop.

Best,
Sven

> --
> You received this message because you are subscribed to the Google Groups "kave-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kave-dev+u...@googlegroups.com.
> To post to this group, send email to kave...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/kave-dev/2476f4ac-b76b-48fa-bb19-239e441860ae%40googlegroups.com.

[Sebastian Proksch]

Thanks for the clarification. However, this raises two additional question:

1) How do you detect when the proposal creation is finished? I guess you don't and you are just processing new incoming additions?

2) Assuming there would be a second proposal provider that is doing the same trick. This would also result in an endless loop, right?

best

Sebastian

[Sven Amann]

On 28.09.2014, at 14:52, Sebastian Proksch <pro...@st.informatik.tu-darmstadt.de> wrote:

> Thanks for the clarification. However, this raises two additional question:
>
> 1) How do you detect when the proposal creation is finished? I guess you don't and you are just processing new incoming additions?

You’re right, we don’t. And we cannot. As the IDE computes proposals asynchronously and opens the code completion before all proposals are added, I don’t see a way to detect this “finished” point. We could ask in the R#-Dev-Forum, though...

> 2) Assuming there would be a second proposal provider that is doing the same trick. This would also result in an endless loop, right?

Yes. I would propose to define a KaVE base class for LookupItems to use for the recursion anchor. Probably we can even find a way to factor out the anchor-check to some provider base class, but I have to look into this.

Best,
Sven