Hi,
I am currently implementing the editor auto-completion and am
thinking on how to have a generic solution for both auto-completion
and the corresponding help information.
There is (sadly) no single extension point to add auto-completion to
any editor and each language has its own interface. Since I already
implemented the CompletionProviderDispatcher class for the shell
auto-completion I thought it would be nice to offer a similar
interface (or even better extend the existing) for editors as well.
This interface would offer a way to parse documents for completion
and return a generic list of proposals. These proposals could then
be parsed by the different scripting languages to the format their
completion extension needs. I guess that this generic list could
also help simplify Vidura's help tips.
In the end I guess we would need:
- The class the completion suggestion belongs to
- The name of the completion suggestion
- The actual object of the completion suggestion with
corresponding type
We already have a ICompletionSource interface that stores
basically this information. If we extend/change the
ICompletionProvider interface to return a list of these
ICompletionSource objects it would be easy to parse them to the
corresponding types for different auto-completion. It would
further make things for Vidura a lot easier (I guess). Do you
agree?
I have been playing around with this solution and I can already
reuse the completion providers for loaded modules and in addition
the call-chain analysis for them. The actual completion providers
are exactly the same, I only use different wrapper methods to have
them in the correct format for the live-shell and the JS editor.
They are loaded dynamically via an extension point so adding new
ones is fairly simple.
Vidura, the ICompletionSource interface should already be
upstream so you could have a look at it (org.eclipse.ease). Maybe
this will simplify your task a bit and in exchange you can help me
with the different type detection features for the editor since we
both need them ;-)
Best regards,
Martin