Community
Participate
Working Groups
Content assist participants need access to the context of the content assist invocation. Some participants may need more information from the compiler's point of view than what is currently available. Requested context elements include (no particular order or commitment, depending on the type of completion): - the invocation offset - bindings for structures enclosing the assist offset, e.g. - annotation binding - binding of the annotated element - enclosing type - ... - the completion token (~ identifier preceding the offset) - logical completion position - in type body - in method body - in assignment RHS - ... AST An AST of the surrounding source is hard to promise as the to-be-completed source code does not generally compile and may not even be syntactically correct. The completion AST created by jdt-core code assist may contain artifical and invalid nodes and does not respect any API contracts. It may change any time and there can be no guarantees of what elements are available in a given situation. Making the completion AST API is therefore not a good idea, but it may be possible to provide a partial AST for certain specific situations. Lifecyle The javaCompletionProposalComputer (name may change) extension point currently provides a ContentAssistInvocationContext to its extensions when computing proposals. The context currently provides information about the editor / document that code assist is invoked in as well as the completion token, but no Java specific information. I would propose to create an java specific subclass (JavaContentAssistInvocationContext) that would allow access to the jdt-core CompletionContext. The completion context would be obtained as today calling ICodeAssist.codeComplete. Jdt-core could extend the completion context to contain more Java specific context information as outlined above.
This is the plan: Content assist participants extend the javaCompletionProposalComputer (name may change) extension point. They get passed a UI context whenever the user invokes content assist. The java version of the UI context allows access to the viewer, invocation offset, compilation unit and also to the JDT Core completion context. JDT core can extend the existing CompletionContext to include/lazily compute the information needed by the various participants. ------ The APIs currently looks like this: interface ICompletionProposalComputer { List<ICompletionProposal> computeCompletionProposals({Text,Java}ContentAssistInvocationContext context); } class JavaContentAssistInvocationContext extends TextContentAssistInvocationContext { CompletionContext getContext(); CompletionProposalCollector getCollector(); ICompilationUnit computeCompilationUnit(); } class TextContentAssistInvocationContext { IDocument getDocument(); int getInvocationOffset(); ITextViewer getViewer(); CharSequence computeIdentifierPrefix(); } Notes: - there is no provision for sorting and filtering yet. The plan is that the UI context will allow (limited?) access to the proposals computed by earlier participants. - ICompletionProposalComputer is defined at jface-text level currently. This will most certainly change (jface-text will not switch to J2SE 5 since it is RCP, and will therefore not allow collection based APIs). If if gets moved to JDT-ui, the API would also change to be JavaContentAssistInvocationContext instead of TextContentAssistInvocationContext. Also its name may change to something closer to 'participant'.
after discussion with David: - CompletionProposalCollector should not be part of the context (as this would allow other participants to call begin/endReporting and such. Instead, we will allow limited (TBD) access to the proposals computed by other participants.
Clarifications after discussions with Dani: - This PR exists only as a preview / discussion area of what jdt-text will offer as code assist context. Interested parties should file separate enhancement requests against jdt-core for additional context information to be included in CompletionContext.
There is a PR in jdt-core for CompletionContext enhancement: bug 110181.
The Mylar Technology subproject filters proposals based on whether or not they are in the current degree-of-interest by briniging these to the top of the list. To do this, it must get a unique handle identifier for the structural element corresponding to the proposal. For Java this is the handle identifier for the IMember corresponding to the MemberProposalInfo. Currently it's quite painful to go from a proposal to the corresponding element, and I think that virutal proxy style identifiers for proposals are contextual information that's useful for any plug-in that wants to filter them. Note that the Java-specific solution would be to open up resolveMember on MemberProposalInfo, or better yet add something like a getCorrespondingHandleIdentifier() method. Could this, or something slightly more generic, bet added too?
The current proposal for javaCompletionProposalComputer looks sufficient for APT. Filtering is still a very interesting feature but we could start with what's currently proposed.
didn't make it - moving to next milestone
The JDT-UI context is there and based on comment 6 and our own experience I believe this PR is fixed. The remaining issues (sorting and filtering) have been moved to bug 119603.
