You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
JDT Core has most of the completion support which triggered as autocomplete on type or manual triggering. It would be nice to allow other extensions to provide completions in either of these scenarios.
One use case is to provide more expensive but smart completions based on receiver type of the expression like in IJ. Another is to integrate extension specific completions such as mapstruct in basic completions.
Most of the existing tooling such as STS4 has chosen to implement a full LS to support features including this behavior as part of java file completion providers.
But for tools like mapstruct which just only need to provide completions, implementing a full LS just to provide completions by parsing source or integrating into JDT.LS through JDT extension point might be expensive route.
Therefore I did a POC on how we can provide a JDT extension point where one could implement a completion provider which will
compute as part of jdt.ls completion phase
provided completions will be run through ranking providers registered into jdt.ls as well
Another route would be to build a library which can be use to bootstrap the LS part where the tooling provider only needs to implement something similar to what above PR provides, but it will be act as a LS on its own and use JDT.LS to resolve AST DOM parts.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
JDT Core has most of the completion support which triggered as autocomplete on type or manual triggering. It would be nice to allow other extensions to provide completions in either of these scenarios.
One use case is to provide more expensive but smart completions based on receiver type of the expression like in IJ. Another is to integrate extension specific completions such as mapstruct in basic completions.
Most of the existing tooling such as STS4 has chosen to implement a full LS to support features including this behavior as part of java file completion providers.
But for tools like mapstruct which just only need to provide completions, implementing a full LS just to provide completions by parsing source or integrating into JDT.LS through JDT extension point might be expensive route.
Therefore I did a POC on how we can provide a JDT extension point where one could implement a completion provider which will
#2653
Another route would be to build a library which can be use to bootstrap the LS part where the tooling provider only needs to implement something similar to what above PR provides, but it will be act as a LS on its own and use JDT.LS to resolve AST DOM parts.
Please provide your feedback.
Beta Was this translation helpful? Give feedback.
All reactions