Re: [jdt-ui-dev] IContentAssistProcessor implementation

[Martin Aeschlimann <martin_aeschlimann@xxxxxxxxxx>]

You're probably not implementing your
own editor, so what you probably want is a way to participate in the code
assist of the Java editor. For Javadoc there's already such an extension
point (org.eclipse.jdt.ui.javadocCompletionProcessor),
and it would make sense to also offer a similar extension point when inside
an annotation.

Martin

Tom Eicher/Zurich/IBM@IBMCH
Sent by: jdt-ui-dev-bounces@xxxxxxxxxxx

01.06.2005 20:54

Please respond to
"Eclipse JDT UI developers list." <jdt-ui-dev@xxxxxxxxxxx>

To	"Eclipse JDT UI developers list." <jdt-ui-dev@xxxxxxxxxxx>
cc
Subject	Re: [jdt-ui-dev] IContentAssistProcessor implementation

Gary,

see my comments inline.

>  we are looking into providing content assistance
>  within annotation elements.

>  the JavaCompletionProcessor is not capable of providing
>  completion proposals for contexts that are inside of String
literals,
>  right?

This is correct: there are currently no proposals inside of strings. 
ICompletionProcessors are registered per partition type, and there is 
currently none for Java string literals.

The Java editor currently does not have such a completion processor, and
neither does it allow to contribute processors to it (see bugzilla for
the relevant bug report). To play with it, subclass 
JavaSourceViewerConfiguration and replace/extend getContentAssistant().

>  Another example of a value content assistant might understand
that
>  the string literal is a reference to a Java type, and call code
>  currently in the JDT to acquire completion proposals.
 >
>  My questions are:
>
>  1. Do we need a new ITypedRegion to dispatch such a content
>  assistant?

Not necessarily - you could also register an ICompletionProcessor for 
the IJavaPartitions.JAVA_STRING partition type which would be smart 
enough (since it can reconcile and have access to the AST) to detect 
whether it is being called from within an annotation element list and 
only return proposals if so.

A example for a similar approach is javadoc: you only get proposals in
some special situations (@tags, <markup>, inside {@links}).

>  2. Is introducing a new ITypedRegion into a Java source
>  document dangerous? Will its presence interfere with something
else?

It migth. Partitions are set up by an IDocumentPartitioner currently 
using a scanner system separate from the compiler's lexer / scanner / 
parser, so adding another partition type may not be trivial. Also note
that partitions do not support nesting, so it would not be possible to
nest the ANNOTATION_ELEMENT type inside JAVA_STRING.

Also, quite many places that deal with the JAVA_STRING partition type 
would have to be adapted to also work with the additional partition type
- for example auto-indenters, autoclosing etc.

Therefore, I think creating an intelligent completion processor for 
string partitions would be the more compatible approach.

-

Also note that code assist in annotation element lists would be 
interesting not just for APT, but also other annotations with string 
arguments - @SuppressWarnings comes to my mind.

-tom
_______________________________________________
jdt-ui-dev mailing list
jdt-ui-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jdt-ui-dev