|
|
|
| Re: Request for "more open code completion"? [message #650429 is a reply to message #647869] |
Mon, 24 January 2011 19:57   |
 Marcel Bruch
Messages: 49
Registered: July 2009 |
Member |
|
|
Hi Dani,
On 10.01.11 09:35, Daniel Megert wrote:
> Did you look at the core context? Also, did you look at the
> 'org.eclipse.jdt.ui.javaCompletionProposalComputer' extension point?
I looked at both and I already use both. But we need more information
than their public api provides. Please have a look on this screencast to
see which information we use and need: http://goo.gl/88Fmu
The existing JDT API has some visibility restrictions when it comes to
details. For instance we need to know the variable name and type code
completion was triggered on etc. - which cannot be accessed from the
completion (core) context
This information, however, is internally available and we would like to
reuse this knowledge for performance reasons. Right now, we create our
own completion engine to get the JDT proposals and context information
(see code below). This takes from 8ms to 800ms depending on when/where
code completion was triggered.
My general question is:
Is it possible to hook into existing code to get more context
information? The information we would like to have can be found in
org.eclipse.jdt.internal.codeassist.InternalExtendedCompleti onContext
and surrounding package.
More detailed:
Is there any way to (a) reuse previous code completion results so that
we only need to compute proposals once, and/or (b) get access to types
and structures stored in org.eclipse.jdt.internal.codeassist.*?
Having access would allow eclipse.org/recommenders to improve
performance of its code completion drastically.
Runtime weaving would be a temporary solution.
Thanks,
Marcel
Code we use to obtain at least a completionParser:
final org.eclipse.jdt.internal.compiler.env.ICompilationUnit compilerCu
= cu.isWorkingCopy() ?
(org.eclipse.jdt.internal.compiler.env.ICompilationUnit) cu
.getOriginalElement() : cu;
engine.complete(compilerCu, jdtCtx.getInvocationOffset(), 0,
cu.getPrimary());
parser = (CompletionParser) engine.getParser();
// analyze whats available in parser assistNode (which is not too much)
|
|
|
|
|
| Re: Request for "more open code completion"? [message #651127 is a reply to message #650790] |
Thu, 27 January 2011 21:30 |
Marcel Bruch
Messages: 49
Registered: July 2009 |
Member |
|
|
sure.
Goal:
Get access to org.eclipse.jdt.internal.codeassist.complete.CompletionOn*
Statements for own code completion.
My hack to achieve this is as follows:
1. Create your own org.eclipse.jdt.internal.codeassist.CompletionEngine
2. Call completionEngine.complete(..);
3. Get the (CompletionParser) completionEngine.getParser()
4. Traver the completionParser.compilationUnit or referenceContext with
your own version of org.eclipse.jdt.internal.compiler.ASTVisitor;
5. Override relevant methods for your code completion task to cast the
CompletionOn* ASTNodes.
Example: to get the information that code completion was triggered on a
method argument you can do the following:
@Override
public boolean visit(final MessageSend messageSend, final BlockScope
scope) {
if (messageSend instanceof CompletionOnMessageSend) {
// here is the requested info:
final CompletionOnMessageSend node = store(messageSend);
// collect info about enclosingMethod and enclosingType
evaluateBlockScope(scope);
// extract info like reveiver type and receiver name:
evaluateCompletionOnMessageSend(node);
// terminate traversal when done:
return false;
}
// in jdt core classes you can find a "CompletionNodeFound" exception
// which you may throw for convenience code. No idea whether this is
// actually costly or not.
return !isCompletionNodeFound();
}
Note that the AST you get from the completion parser is a "diet"
version. It only contains nodes relevant for code completion, i.e.,
declared local variables, fields, and methods but (almost) no other
statements.
I guess the source code will make it little bit easier to grasp. I can
send you the two classes per mail or post the link to source repository
in a few days after we moved code completion to Eclipse.
One note on performance:
Parsing the code of tiny classes takes ~10ms. Haven't tested with large
classes yet.
Cheers,
Marcel
On 26.01.11 16:15, Sebastian Zarnekow wrote:
> Marcel,
> can you elaborate in a few words what you did to solve your problem?
>
> Thanks,
> Sebastian
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03851 seconds
] 
Search
Help
Register
Login
Home
