Community
Participate
Working Groups
Today java editor content assist processors are backed by the single jface text content assist processor. The JDT computers then runs parallel and wait till all computers are done processing. This leads to note using the async content assist to its proper use. If we can run jdt completion computers in the same way the jface content assist processors runs, then we can provide the results of faster computers first and let the slow ones to provide result with a delay. This make a better developer experience since you don't need to wait till all computers are finish. This way we can enable slow/expensive computers such as chain completions by default. Suggestion1: Add support to add new assist processors with a new Editor configuration extension point such as in wst xml editor. Suggestion2: Extend the current jdt completion computer extension point to support this behavior and keep the existing behavior as default.
@Kalyan @Lars @Mickael @Andrey what do you think about this idea ?
I have added @vikas to the cc list for his opinion too. Only the ui part of the content assist support is implemented in JDT UI. The actual content assist processing happens in JDT Core.
@Kalyan @Vikas i'm considering to have a change here while keeping the rest of the completion design as it is. org.eclipse.jdt.ui.text.JavaSourceViewerConfiguration.getContentAssistant(ISourceViewer) But saying that i think we need to consider the sorting implementation we have on the JDT completion computer completions. Therefore i also thought to keep the main completions computers unchanged and add a new extension point in JDT to add long running completion processors directly added here as a processor and move the sorting to jface ContentAssistant. All these are just some idea which i have't looked deep into implementation. Let me know what you think as well.
On the other hand i'm also thinking that could it be a good idea to extend the jface text org.eclipse.jface.text.contentassist.IContentAssistProcessor to support CompletableFuture as the result instead of array of ICompletionProposal. This way we can use two different completion processors in JDT based on whether all JDT computers support async or not. One will use what we have today in JDT, but if all support async, then we will use the new extension to provide CompletableFutures, this way we could share the ContentAssistInvocationContext to avoid each IContentAssistProcessor to create its own context or keep the context in static scope to share among different IContentAssistProcessor. @Lars @Mickael what do you think about this Platform idea ?
(In reply to Gayan Perera from comment #4) > On the other hand i'm also thinking that could it be a good idea to extend > the jface text org.eclipse.jface.text.contentassist.IContentAssistProcessor > to support CompletableFuture as the result instead of array of > ICompletionProposal. This way we can use two different completion processors > in JDT based on whether all JDT computers support async or not. > > One will use what we have today in JDT, but if all support async, then we > will use the new extension to provide CompletableFutures, this way we could > share the ContentAssistInvocationContext to avoid each > IContentAssistProcessor to create its own context or keep the context in > static scope to share among different IContentAssistProcessor. > > > @Lars @Mickael what do you think about this Platform idea ? Thought about this more looking at the jface text implementation. And i think the above idea will not work given that completable future can only be complete once.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
