CDT Content Assist Feature Spec
 Requirements and design proposal for CDT 2.0 release.
Author : Hoda Amer
Revision Date : 12/12/2003 - Version: 0.3.0
Change History : 0.1.0 - Document Creation
: 0.2.0 - Document Update
: 0.3.0 - Document Formatting, Requirements Update by Brent Nicolle
Table of Contents

1. Introduction
2. Requirements
3. Design Notes
4. CDT Design Overview
5. References


1. Introduction

This feature is often also called code assist. However, the concept originates in the Eclipse Platform with the JFace text editor. As such, this feature applies to more than just code. Besides, the interface is called IContentAssistant.

Content assist is a feature that is heavily used in many development environments and developers soon rely on it since it is such a great productivity enhancer. This feature is seen as critical to the acceptance of the CDT by the mass C/C++ development community.

In this document, requirements and proposals are associated with a priority Pi, that indicates its implementation priority, such that

[P1]: Top priority

[P2]: High priority

[P3]: Medium priority

[P4]: Low priority

In the current plan, we are committed to implementing everything that is assigned a priority of P1 or a P2. These priorities, along with our commitments,  could be revisited and changed later in the development cycle according to time and resources availability.

2. Requirements

Content Assist Functionality

Req.# Priority Description
1 [P1] A request for content assist proposals occurs whenever a certain combination of keys is pressed (for example CTRL+SPACE).
1.1 [P1] Content assist could be requested at any place in any document.  (However, a request may generate no proposals.)
1.2 [P2] Content assist may be configured for auto-activation, when an appropriate pause in typing automatically generates a request for content assist.
2 [P1]

When invoked, content assist will present a scrollable list of potential code fragments that can be inserted at the current cursor location. Content can be inserted from all of the following sources:
2.1 [P1] Code completion.  See functionality itemized separately below.
2.2 [P2] Code templates.  This presents a list of code templates that can be applied in the current cursor position.  Example templates can include C code structures such as 'for' statements, or larger templates like classes or member functions. 
2.3 [P3] Virtual member function overrides.  When the cursor is at an appropriate place in a class, the list of potential virtual method overrides would be supplied in the completion list.
3 [P1] Filtering by prefix. When the completion request occurs where the cursor follows an alphanumeric sequence ("a prefix"), the prefix is used to filter proposals that begin with the prefix.
3.1 [P1] Continued typing of alphanumeric keys after the request causes continued filtering of the proposals.
3.2 [P1] Backspacing through the prefix may or may not continue content assist.
3.3 [P1] A content assist request without a prefix can be used to browse an appropriate list of code completions.
4 [P1] Proposals are presented in order of likely relevance, by default.
4.1 [P1] Each proposal must have an associated relevance number that could be used to order proposals.
4.2 [P2] The user can instead choose to sort all proposals alphabetically.
5 [P1] When a proposal in the proposal list is selected by mouse or by keyboard, an additional pane will open up presenting additional information, if available.
6 [P1] A proposal is accepted by double-click or by pressing Enter, and the proposal is expanded at the cursor insertion point.
7 [P1] The user can always type something not in the proposal list.
8 [P1] The proposals list may be dismissed by mouse or by keyboard.
9 [P1] The feature must not regress from CDT 1.2.  The CDT already provides an implementation of the content assistant. Any changes must be co-ordinated carefully to ensure existing functionality isn't compromised.

Code Completion Functionality

Req.# Priority Description
10 [P1] Code completion suggests symbols, function calls and keywords that can be inserted at the current location.  Proposals from code completion include:
10.1 [P1] calls to global functions or use of global variables
10.2 [P1] use of local variables
10.3 [P1] use of types
10.4 [P1] calls to member functions and use of member variables
10.5 [P2] keywords
11 [P1] Code Completion proposals must take into account the current context information and the current scope. Scoping rules might differ for the current language variant (e.g. link scope for C)
(4.1) [P1] Each proposal must have an associated relevance number that could be used to order proposals.
(3.3) [P1] A content assist request without a prefix can be used to browse an appropriate list of code completions.
12 [P2] The inserted Completion Proposal should not produce a compilation error. Completion will try (best effort) to avoid completion suggestions that would cause a compilation error.

Examples of Code Completion Functionality

Examples where code completion is requested:

1. Unqualified names in a function [P1]

int aVar;

void aFunction(bool);

struct aStruct { int b; };

 

void foo(){

    a(CTRL+SPACE)

}

Resulting proposals include:

aVar

aFunction(bool)

aStruct

2. Qualified Member Reference [P1]

class D{

    int aVar;

    void aMethod (int i);

};

void foo(){

    D d;

    d.a(CTRL+SPACE)

}

Resulting proposals include:

aVar

aMethod(int)

3. Qualified Member Reference without a prefix [P1]

class X {

    int aVar;

    int bMethod(int i);

};

void foo(X* x){

    x->(CTRL+SPACE)

}

Resulting proposals include:

aVar

bMethod(int)

User Preferences

Req.# Priority Description
13 [P1] It is required to have a set of flexible user preferences that could be used to tailor the look and the order of the given proposals.

C Language Support

Req.# Priority Description
14 [P1] It is required to have C Language support.
14.1 [P1] C compilers allow functions and variables to be implicitly declared.  Content completion allows C users to complete functions and variables that have not been explicitly declared, but are in the project or in a depended C project.
14.2 [P3] A C developer should not see constructs which are specifically C++.

Extensibility

Req.# Priority Description
15 [P1] An extensibility mechanism is required for third parties to provide additional information (such as listed below) for some completion proposals.
15.1 [P3] Documentation extension for code completions. This can come from a number of different places and thus, should be extensible. Example extensions would include doxygen style documentation, documentation databases, man pages, etc.
15.2 [P3] Preview extension of a completion proposal. This would be for code templates and virtual member function overrides to show what text will be inserted at the cursor location.
16 [P2] The list of code templates must be extensible to allow plugins to provide additional templates.

Performance

Performance is a key requirement for content assist.

Req.# Priority Description
17 [P1] A key benefit of content assist is to speed up the creation of code content. If it takes longer for the completion proposals to be calculated than it would to type in the desired text, then this benefit is lost. It is better to provide an incomplete list of proposals than to take more than the reasonable amount of time. The actual time that would serve as this requirement is subjective.
17.1 [P2] It should not take more than three seconds to find proposals.
3. Design Notes

In JDT, Content Assist (also called Code Assist) is a broad term. It includes Code Selection and Code Completion. Code Selection is concerned with finding context information, such as mapping the current selection in the editor to a possible model element, while Code Completion is concerned with finding possible completions at the current cursor position when a certain combination of keys is pressed. To help enhance code assist in CDT 2.0, we are proposing a design similar to the one in JDT that depends on parsing the current document and trying to predict the logical completions at the cursor position.

Architectural Notes

Clearly, the extension mechanism provided by the SourceViewerConfiguration shall be used to implement a content assistant.

JDT Design Overview

Code assist in JDT is used for two purposes:

  1. Context Information: If some source is selected in the editor, try to find the Java model element that corresponds to it.
  2. Completion Proposals: If some special key combination is pressed, try to find completion proposals that would fit after the current cursor position.

This document describes the completion proposals part of code assist only (not including template completions).

The request to for code assist arrives through jface to the editor’s source viewer. The JavaSourceViewerConfiguration class assigns one or mode completion processors. It creates the JavaCompletionProcessor and forwards the request to it. The JavaCompletionProcessor finds the current document’s working copy and forwards the request to it in turn. It also created a result collector to receive all proposals. The request includes the current cursor position.

The working copy uses the CompletionEngine for code completion. The CompletionEngine class is the entry point for code completion. Completion proposals are computed and sent to an ICompletionRequestor. Each proposal has an associated relevance; a positive integer that may be used to compare this proposal to other suggested proposals. The relevance of a code completion candidate can be affected by the expected type of the expression, as it relates to the types in the surrounding code, such as variable types, cast types, return types, etc.  The presence of an expected prefix or suffix in a completion also affects its relevance.

When asked to complete on a certain compilation unit, the completion engine parses the compilation unit without going into function bodies (using CompletionParser.dietParse()). The Completion Parser, a subclass of Parser, estimates the AST node being completed. The AST node being completed could be one of the following:

CompletionOnArgumentName, CompletionOnClassLiteralAccess, CompletionOnClassReference,  CompletionOnExceptionReference,  CompletionOnExplicitConstructorCall,  CompletionOnFieldName, CompletionOnFieldType, CompletionOnImportReference, CompletionOnInterfaceReference, CompletionOnKeyword, CompletionOnLocalName, CompletionOnMemberAccess, CompletionOnMessageSend, CompletionOnMethodName, CompletionOnMethodReturnType, CompletionOnPackageReference, CompletionOnQualifiedAllocationExpression, CompletionOnQualifiedClassReference, CompletionOnQualifiedExceptionReference, CompletionOnQualifiedInterfaceReference, CompletionOnQualifiedNameReference, CompletionOnQualifiedTypeReference, CompletionOnSingleNameReference, CompletionOnSingleTypeReference.

Some of the above nodes could be found even when parsing without going into function bodies (performing a diet parse). For example, CompletionOnPackageReference and CompletionOnImportReference could occur as a result of a diet parse. The completion engine checks these possibilities one by one. If it finds that the compilation unit's package is an instance of CompletionOnPackageReference, it searches for the possibilities of the enclosing package. Similarly, if it finds that the completion is required for an import (i.e. one of the imports is an AST node of type CompletionOnImportReference), it searches for possibilities on that particular import. Finally, if non of these possibilities is true, it proceeds and parses the method in which completion is required.

Right before parsing the method in which completion is required, the Completion Engine builds the type bindings. This means it converts the types (classes) in the parsed compilation unit from AST nodes into scopes and bindings. This will help determine the scope of each type and its hierarchy and resolve any relationship it might have with an interface or an inner class. For example, using a class binding, you could get its super class and all its methods, etc...

Using the given position and information about the beginning and end of each method binding in the parsed compilation unit, the Completion engine determines the method in which completion is required and parses its body as a block of statements without balancing brackets. Here the parser estimates the completion node and determines its type. The engine checks possibilities one by one. Assuming that it found out that the completion node is of type  CompletionOnSingleNameReference, it does the following:

    - Find all variables and methods that would fit the given criteria ( visibility, prefix, etc...) by looping in two dimensions: one checking the scope and the other checking the hierarchy. The algorithm does the following:

            1. Get the current scope

            2. If it is a Type scope, then find all possible variables and methods,

            3. filter the ones meeting the given criteria and calculate a relevance for each proposal.

            4. Check for any interface implemented by that type and find their methods as well

            5. Get the parent class

            6. Loop for all parent classes and perform the same checks until you reach no parents (the object class)

            7. Loop for all enclosing scopes until you reach the scope of the compilation unit.

For each possible AST completion node, there is an associated algorithm that tries to find relevant matches. The search engine is sometimes used to find occurrences of some elements; for example, finding all methods that start with "a" in a particular class and its hierarchy.

Finally, all results are sent to the ICompletionRequestor and a sorting is performed on them. They are automatically displayed in the appropriate window.
4. CDT Design Overview

There are several sources of input to completion proposals:

1. The Completion Engine

The Completion Engine depends on the parser to know the current scope, context and the prefix to complete on.

 

2. The Template Engine

There are some user defined templates the Template Engine searches to get matching proposals. The current scope and context are two more parameters that the Template Engine must use in filtering the relevant templates.

 

3. Extension points

There is an already defined extension point to allow vendors to provide completions given a prefix. This should be extended to provide the scope and context as well.

 

4. Search

Search will be used only if the selected completion scope is wider than the current document scope (i.e. the current project scope or the scope of the current project + the projects it depends on).

This section discusses the high level design of the Completion Engine.

As described in the previous section, code completion in JDT is composed mainly of two parts: the Completion Parser, and the Completion Engine. The parser attempts to predict the AST node being completed. The Completion Engine generates the proposals by checking the possibilities one by one and performing the relevant searches accordingly. It also calculates the relevance associated with each proposal.

Just like in the JDT, the request for code completion arrives through jface to the editor's source viewer. The CSourceViewerConfiguration class creates the CCompletionProcessor and forwards the Code Assist request to it. The CCompletionProcessor forwards the request in turn to the current document's working copy for processing. Completion proposals are eventually sent to the completion requestor.

The working copy of the current document will use a CCompletionEngine to compute proposals. In CDT, code completion will consist of three main parts: Parsing using a completion parser, searching for symbols with certain criteria, and computing proposals and their relevance.

The Completion Parser

Currently the CDT parser does not have a completion mode. A new mode for the CDT parser will be implemented for code completion. Given a Translation unit and a cursor position, the parser will figure out what is the current completion scope. It will also predict the completion node, which indicates the types of proposals to look for in the given completion scope. Finally, the completion parser will return the prefix, if any, that all proposals should match.

In the example Single Name Reference, the completion scope in which search should take place would be the AST node that represents the function foo(). The completion node would be of type CompletionOnSingleNameReference, and the types of proposals to look for would be global variables, local variables, methods, keywords, and classes accessible from within that scope. The prefix to match would be "a".  In the example Basic Qualified Member Reference , the completion scope to search in would be the AST node that represents the class D. The predicted completion node would be of type CompletionOnMemberReference, and what to look for would be methods and fields of that class scope (including all its hierarchy). The prefix to match in this case is also "a".

Types of Completion Nodes

Completion could be requested anywhere in a translation unit. To help identify the logical place where completion is requested, we defined a set of completion nodes types. Each type of completions is given a priority Pi indicating its implementation priority as previously explained.

Completion nodes could be one of the following types:

Completions on Types [P1]:

Completion on a type could be for a variable type,  a field type, or an argument type. If the parser indicates that completion is on a Type, proposals will include all built-in types as well as all visible defined types matching the given prefix.

- Completion on Field Type will occur in the scope of a class, struct or a union, where the user would typically be starting a new declaration. In this case, the declaration could be a new field or a new method. We have no means of differentiating between the two cases as no knowledge is assumed after the given cursor position. In this case, the search scope for relevant proposals is the enclosing structure scope.

- Similarly, completion on Variable Type will occur in a global scope (or in a namespace scope) where the user would typically be starting a new declaration of a type, a variable or a method. The search scope for relevant proposals in this case is the enclosing scope.

- The completion on Argument Type will occur in a function / method declaration after a "(" or a ",". The search scope will be the enclosing scope of the function / method.

 

CompletionOnFieldType

Example :

classA {

    in(CTRL+SPACE) è int

};

 

CompletionOnVariableType

Example :

vo (CTRL+SPACE)  foo(int) è  void foo (int)

 

CompletionOnArgumentType 

Example :

void foo( in(CTRL+SPACE) è void foo(int

 

 

Completions on Members and Scoped References [P1]:

 

Completion on members references is a completion request after a “.” or an “->”, while completion on scoped references is a completion request after a “::”. The search scope for relevant proposals will be the scope of the type before the ".", "->" or "::". 

Note that the search scope could be simple ( only a symbol or a scope ) or complex ( the result type of an expression ). 

CompletionOnMemberReference

Example:

void foo(){

    a.(CTRL+SPACE)

}

void foo(){

    ((D*)func())->(CTRL+SPACE)

}

         CompletionOnScopedReference

Example:

void foo(){

    A::(CTRL+SPACE)

}

 

 

Completions on References [P1]:

Completion on a reference is indicated whenever a name, structure, an exception or a function/method is referenced:

- The completion on single name reference will occur in a statement. The search scope is the enclosing scope of the code block ( function / method ).

- A completion on a type reference  is requested when a type is expected (either a built-in type or a user defined type); for example, after the "new" operator.

- A class reference (or a class template) is a special kind of a type reference, and is found when completion is required after the keyword "public" in a declaration of a class.

- A namespace reference is a special kind of a type reference, and is found when completion is required after the keyword "using".

- An exception reference is another special kind of type reference and is found in a "catch" clause. If no prefix is provided, (…) should be one of the given proposals.

- A function reference is found in a call to a predefined function / method, or function template implicit instantiation. The list of expected parameters appears in a box above the cursor level. The little box should also indicate if there are default values to the parameters. The "TAB" key should be used to exit the editing of parameters mode.

- Completion on constructor parameter list is indicated when completion is requested on a constructor call. Only the constructed class scope is searched and only constructors of that class are proposed.

 

            CompletionOnSingleNameReference

Example:

int foo(int i){

    a(CTRL+SPACE)

}

 void foo(){

     ((D*)func())->a(CTRL+SPACE)

 }

CompletionOnTypeReference

            A Reference to a built-in type or a user defined type is expected.

            Example :

      BType b = new B(CTRL+SPACE)

 

CompletionOnClassReference

Only a reference to a class type (or a class template) is expected.

Example:

class Derived : public Ba(CTRL+SPACE)

 

CompletionOnNamespaceReference

Only a reference to a namespace expected.

Example:

using n(CTRL+SPACE)

 

CompletionOnExceptionReference

Completion must be on a thrown Exception

Examples:

try {

} catch (IOExc(CTRL+SPACE) e) {

}

 

CompletionOnFunctionReference

Show suggestions for parameters using the called function definition in a special box

Proposals should take into account argument default values.

This case can cover both calling a method and implicit function template instantiation.

 

Example:

void foo(int x , int y = 1, int z = 2);

void bar(){

                        int x, int y = 1, int z = 2

 foo( CTRL+SPACE è foo(

}

 

CompletionOnConstructorReference

We search the constructors of a class only.

Example:

BType b = new BType ( (CTRL+SPACE)

 

Completion on Keywords [P3]:

Completion on keywords is indicated when completion is requested in the position of a keyword. The C/C++ keywords list is searched. Only keywords matching the given prefix are proposed.

CompletionOnKeyword

Completion position matches a keyword position

Example:

    try {} ca(CTRL+SPACE) è try {} catch 

    class X pub(CTRL+SPACE) è class X public

 

Completion on Preprocessors:

Proposes completions for includes and macros. In this case, the indexer will be queried for the known possible completions. To avoid performance overheads, the indexer will be asked to provide what it can within a certain time limit.

CompletionOnIncludeReference [P4]

Example:

#include "std( ctrl + space) è #include "stdio.h"

 

CompletionOnMacroReference [P2]

Example:

#ifdef  MAC(ctrl+space) è #ifdef MACRO 

Completions on Names [P4]:

Completion on names gives suggestions for variables, fields, arguments, or local variables names.

CompletionOnFieldName

CompletionOnVariableName

CompletionOnArgumentName

CompletionOnLocalName

Example:

int (CTRL+SPACE) è int i;

bool (CTRL_SPACE) è bool b; (unless you already have a variable named b, in this case it gives you bool c).

 

Interface between the Completion Engine and the Parser

The Completion Engine will call the parser, passing to it the completion offset. It expects back a prefix, a scope and a completion node type. The parser will return an object that implements the following interface:

public interface IASTCompletionNode {

public static class CompletionKind extends Enum

{

public static final CompletionKind FIELD_TYPE = new CompletionKind( 0 );

public static final CompletionKind VARIABLE_TYPE = new CompletionKind( 1 );

public static final CompletionKind ARGUMENT_TYPE = new CompletionKind( 2 );

public static final CompletionKind MEMBER_REFERENCE = new CompletionKind( 3 );

//TODO MORE TO COME

/**

* @param enumValue

*/

protected CompletionKind(int enumValue) {

super(enumValue);

}

 

}

 

public CompletionKind getCompletionKind();

public IASTNode getCompletionContext();

public String getCompletionPrefix();

}

The IASTCompletionNode will have a Completion Kind indicating the type of completion node, a completion context IASTNode indicating the search scope, and a prefix to match.

The Symbol Table Lookups

After parsing a Translation Unit in CDT and following includes, the Symbol Table has information about all symbols in this translation unit's lookup environment. We intend to make use of this ready to use information and look for symbols with certain criteria (e.g. prefix) in the translation unit's lookup environment.

Since the Symbol Table is internal to the parser and should not be accessed directly, lookup methods will be added to AST nodes, which could be thought of as wrappers for the Symbol Table. For example, an AST Node that implements the IASTScope will be able to search for all symbols that start with a certain prefix within the lookup environment of this scope. The result of search would be a list of all AST nodes matching the given criteria. AST Nodes also contain visibility information and can determine if one virtual function is hidden by another. This information will be used by the completion engine in computing the proposals and their relevance.

Search Scopes

Search scopes will be determined by the parser. The search scope could be the scope of a type (structure), the scope of the translation unit, or a code scope of a function/method. Some C projects require wider search scopes. In this case, in addition to the normal lookup, a search operation will be invoked with the preferred scope.

 

Suggested scopes are:

Current translation unit following all its included header files. ( normal lookup )

Current project only.

Current project and the projects it depends on.

Required Lookup API

The current implementation of the lookup table needs to be changed to suite the needs of a content assist lookup. To facilitate symbol table lookups, a lookup API needs to be added to the IASTNode interface, an interface which represents any AST node that might have a representation in the symbol table. Currently internal lookups look for a certain name. The new API should be able to take a prefix to match, not necessarily a whole name. It also should return all found matches. Currently if more than one alternative is found, the returned value is null.

The suggested API will take as a parameter the prefix to match and an object of type "LookupKind" that determines the type it is looking for. The API will return an object of type "LookupResult" that has the list of found ASTNodes and a possible set of matching keywords if some are appropriate.  The APIs should return "null" if nothing is found.

Here is a suggested IASTNode interface and its lookup API:

 

public interface IASTNode {

 

public static class LookupKind extends Enum {

public static final LookupKind ALL = new LookupKind( 0 );

public static final LookupKind STRUCTURES = new LookupKind( 1 );

public static final LookupKind FUNCTIONS = new LookupKind( 2 );

public static final LookupKind LOCAL_VARIABLES = new LookupKind( 3 );

public static final LookupKind METHODS = new LookupKind( 4 );

public static final LookupKind FIELDS = new LookupKind( 5 );

public static final LookupKind NAMESPACES = new LookupKind( 6 );

/**

* @param enumValue

*/

protected LookupKind(int enumValue) {

super(enumValue);

 

}

}

 

public static class InvalidLookupKind extends Exception

{

}

 

public static interface LookupResult

{

public String getPrefix();

public Iterator getNodes();

public Iterator getKeywords();

}

public LookupResult lookup( String prefix, LookupKind kind );

}

 

What kind of elements are looked up?

 

According to the returned completion node type, a lookup for certain element's type will be done. The following table summarizes the completion node types and the expected lookups. It also indicates what elements are looked up with an empty prefix. If no prefix is provided, some lookups are considered very expensive (namely Types and global variables lookups) and will be avoided.

 

Type Of Completion Node Elements to lookup

If no prefix is provided
CompletionOnFieldType

Types in scope

Built-In types

Constructor

Destructor

Keywords : public, protected, private, const, static, friend

New inner class start : class

Same, except no Types in scope.
CompletionOnVariableType

Types in scope

Built-In types

Keywords: const, static, extern

New user defined type start : class, struct, union, enum

 Same, except no Types in scope.
CompletionOnArgumentType

Types in scope

Built-In types

Keywords: const

Same, except no Types in scope.
CompletionOnMemberReference

Members (Fields / Methods) in type with the right visibility with respect to the enclosing scope

Same
CompletionOnScopedReference

Static members (fields / methods) in type

Variables in namespace

Types in namespace

namespaces in namespace

Same
CompletionOnSingleNameReference

variables (local/ fields/ global) in scope

Methods / Functions in scope

Types in scope

Built-In types

 Same, except no Types in scope and no global variables.
CompletionOnTypeReference

Types in scope

Built-In Types

Same, except no Types in scope.
CompletionOnClassReference

Classes

Same.
CompletionOnNamespaceReference

Namespaces

Keyword : namespace

Same.
CompletionOnExceptionReference

Types in scope

Built-In types

"..."

Built-In types
CompletionOnFunctionReference

variables (local / fields / global) in scope

methods /functions in scope

namespaces in scope

Same.
CompletionOnConstructorReference

Possible constructors of class

Same.
CompletionOnMacroReference

Macro definitions

Nothing.
CompletionOnIncludeReference

possible include file names within the scope of the include directories of the current project.

Nothing.
CompletionOnKeyword Applicable keywords

Same.

 

The Completion Engine

The Completion Engine will call the completion parser.  It will then examine the returned scope and completion node and look for all possible proposal types with the given prefix. If there is only one proposal, the Completion Engine might want to simply insert it in the current cursor position. Otherwise, proposals will be ordered according to their relevance and sent for display.

How is the Relevance number calculated?

In the default case, the relevance number responsible for ordering proposals is calculated according to three categories: the element type, the case matching, and the element scope.

According to types, elements will be given relevance numbers according to the following order:

 

1. Fields                // Highest relevance

2. Variables

3. Methods

4. Functions

5. Classes

6. Structs

7. Unions

8. Namespaces

9. Enumerations    // lowest relevance

 

Each proposal is checked against the given prefix. If the user starts a proposal with a lower case , e.g. "a" , all proposals starting with a lower case will be given a higher relevance than proposals with any other case.

 

For the element scope, the closer the scope is, the higher the associated relevance number. Finally, each proposal adds its type + case + scope associated relevance numbers to come up with its proposal relevance number.

 

This default case could be overridden if the "order proposals alphabetically" preference is implemented and is chosen. In this case, the relevance number will be ignored.

 

When not to expect any completion proposals?

In some cases, no completion entries will be provided. Examples of these cases will be:

1. When completion is requested in a code portion that is not compiled, or in a commented out code.

Example :

 

#ifdef 0

    a(CTRL+SPACE)

#endif

 

2. In expressions mainly because partial expression results are hard to evaluate.

Example:

 

s  = 2 + f(CTRL+SPACE)

x [ i(CTRL+SPACE)

 

 

What if the current code has compilation errors?

If the current code has compilation errors, completions could still be requested. However, it would be a best effort kind of job and if the parser is totally lost, no completion entries would be expected.

The Content Assist Preference Page

Here are some suggestions for enhancing the existing content assist preference page.

Auto Activation [P2]:

Change the auto activation section to be in a group, named “Auto Activation”- on by default:

Checkbox - Use “.” as trigger

Checkbox - Use “->” as trigger

Checkbox - Use “::” as trigger

Textbox - Delay (in ms) with default 500

Search Scope [P1]:

Add a search scope group, named “Search Scope” - first option selected by default.

Radio button - Search current file and included files only

Radio button - Search current project only

Radio button - Search current project and dependent projects   

Sorting Proposals [P3]:

Add a sorting preference - off by default.

Checkbox - Present proposals in alphabetical order

5. References

JDT source code.

CDT Content Assist Feature Spec for CDT release 2.0 . see http://www.eclipse.org/cdt/