This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
There are a several request (mostly from authors of some Groovy-based framework plugins) asking for some API which allows to provide additional code completion results. There are basically two use cases that we should handle at the moment: 1) Adding more default imports (requested by Gradle plugin author Attila Kelemen) 2) Adding more code compeletion results for a certain context () First point should be trivial, second point will need a little bit more work as it is not obvious at the moment how many and which exact information we should provide as "context" (there might be possibly a lot of different use cases each specific per Groovy based framework). I'll try to create sketch of the possible solution and we will see if it's enough at least for the current use cases.
First sketch of the possible implementation done in: web-main #da561ee9884e Now there is a possibility to register CompletionProvider using @ServiceProvider annotation. Few things that still needs to be done: 1) Rewrite the rest of the Groovy code completion handlers to use the same approach (which is using global CompletionContext class with an information about what is the current context) 2) Improve JavaDoc for SPI/API classes 3) Make the CompletionContext more user-friendly containing only the important information (currently everything that was used in the old implementation is there, but a lot of things doesn't seem to be needed) 4) Clean-up the rest of the groovy.editor so the API packages will really contain only API classes. All the *Something*Utils classes should be moved to a different module (e.g. groovy.utils), api.elements package and it's subpackages shouldn't be needed by the clients and therefore they might be in "normal" non-API packages.
MetaElementHandler rewrite to new CompletionProvider: web-main #be6e1fc5f174
> There are basically two use cases that we should handle at the moment: > > 1) Adding more default imports (requested by Gradle plugin author Attila Kelemen) > 2) Adding more code compeletion results for a certain context () > > First point should be trivial, second point will need a little bit more work What about doing the first point only as a first step? Did you happen to find out if it is trivial?