Comment 1 Marcel Bruch 2012-01-07 01:06:11 EST

FWIW, this bug report has its origins here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=340945

Comment 2 Dani Megert 2012-01-10 09:40:06 EST

Whether the extended context is available in the first invocation already depends on the enabled categories and whether argument names are requested. It's up to each processor to request the extended context by calling setRequireExtendedContext(true) on its own collector.

Comment 3 Marcel Bruch 2012-01-10 10:37:51 EST

I wasn't aware that it's the responsibility of the engine to recreate the context if it's not extended. After digging into JavaCompletionProposalComputer#internalComputeCompletionProposals and its subclasses this became clearer to me. I added the some additional logic to my code that creates and  extended context if the currently given one isn't an extended one. This still looks odd to me but it seems to work. Please let me know if this violates or breaks some JDT concepts. Thanks for your assistance!


    public BaseRecommendersCompletionContext(final JavaContentAssistInvocationContext jdtContext) {
        this.javaContext = jdtContext;
        this.coreContext = cast(jdtContext.getCoreContext());
        if (!coreContext.isExtended()) {
            requestExtendedContext();
        }
    }

    private void requestExtendedContext() {
        CompletionProposalCollector collector = new CompletionProposalCollector(getCompilationUnit()) {
            @Override
            public void acceptContext(final CompletionContext context) {
                super.acceptContext(context);
                coreContext = (InternalCompletionContext) context;
            }
        };
        collector.setInvocationContext(javaContext);
        collector.setRequireExtendedContext(true);
        try {
            getCompilationUnit().codeComplete(getInvocationOffset(), collector);
        } catch (JavaModelException e) {
            log(e)
        }
    }

Comment 4 Dani Megert 2012-01-11 06:20:03 EST

(In reply to comment #3)
> I wasn't aware that it's the responsibility of the engine to recreate the
> context if it's not extended. After digging into
> JavaCompletionProposalComputer#internalComputeCompletionProposals and its
> subclasses this became clearer to me.

> I added the some additional logic to my
> code that creates and  extended context if the currently given one isn't an
> extended one.
You don't need to check. Simply request it. Don't you already need/have a collector to get the proposals from JDT Core? If so, simply require it on this collector. If not, how do you get the proposals from JDT Core without collector?

> This still looks odd to me
The main purpose is to avoid additional computation if it is not needed.

> but it seems to work.
Of course ;-)

Comment 5 Marcel Bruch 2012-01-11 06:29:58 EST

(In reply to comment #4)
> Don't you already need/have a
> collector to get the proposals from JDT Core? If so, simply require it on this
> collector. If not, how do you get the proposals from JDT Core without
> collector?

I changed that part for Juno. I now create my own proposals w/o using cu.codeComplete. I though this would be 'smarter' than requesting all proposals first and filtering them afterwards.

Comment 6 Dani Megert 2012-01-11 06:32:57 EST

> I now create my own proposals w/o using
> cu.codeComplete.
Why do you then need the context from JDT Core, then?

Comment 7 Marcel Bruch 2012-01-11 06:38:43 EST

(In reply to comment #6)
> Why do you then need the context from JDT Core, then?
To get access of all visible locals, methods, fields and the *Completion node.

The latter is used to figure out on which variable (name and type) or type (static) completion was triggered and what kind of proposals we want to make. For call completion a pure filtering could work (given that we get simple access to the variable's type completion was triggered on. Other engines like template completion need more information to filter which templates may apply in the given completion context.

Comment 8 Dani Megert 2012-01-11 06:43:31 EST

(In reply to comment #7)
> (In reply to comment #6)
> > Why do you then need the context from JDT Core, then?
> To get access of all visible locals, methods, fields and the *Completion node.
> 
> The latter is used to figure out on which variable (name and type) or type
> (static) completion was triggered and what kind of proposals we want to make.
> For call completion a pure filtering could work (given that we get simple
> access to the variable's type completion was triggered on. Other engines like
> template completion need more information to filter which templates may apply
> in the given completion context.

I see. Makes sense.