Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] DOMCompletionContributor findings

Hi folks,
 
I have ported the first unit test from CCompletionProcessor to
CCompletionProcessor2. The code is in package
org.eclipse.cdt.ui.tests.text.contentassist2, parallel to the
org.eclipse.cdt.ui.tests.text.contentassist package. This should make it
easy to compare the code for the test cases.

Here are some things I have found while reviewing the unit tests for
CCompletionProcessor to  which I would like to put up for discussion. To
start with something I took a testcase which I considered as a simple
case namely
org.eclipse.cdt.ui.tests.text.contentassist.CompletionTest_FunctionRefer
ence_Prefix - the corresponding cpp source file is
org.eclipse.cdt.ui.test/resources/CompletionTestStart36.cpp
 
This test case requests completion proposals for prefix "x" inside a
function parameter list.
 
- CCompletionProcessor2 does not find the macro definition XMacro(x,y)
which is found by CCompletionProcessor. Can it be that
CDOM.getCompletionNode() is case sensitive? The CCompletionProcessor
apparently used a case insensitive method and this is what I would
expect as the behavior of code completion.

- For all non-function proposals no type is given in the completion
proposal. The original tests require that for global variables the type
is given after a colon. Like so:

    (CCompletionProcessor2)    xLocal
    (CCompletionProcessor )    xLocal : int

The fix would be to make extra handler functions in
DOMCompletionContributor for variables which do the desired formatting.
I find it useful to have the type information shown if it is available.
Is it worthwhile tuning the DOMCompletionContributor? Or will it
replaced by PDOM stuff anyway?

Hope I am not boring anybody to desperation; I would just like to access
the community's memory to learn about why things are the way they are. 

Also I think that the unit tests are there to guarantee the quality of
the code and may uncover some weaknesses of the current completion
processor (and underlying CDOM) implementation. So all who are
interested in this, pse be attentive.


Thanks,


Norbert Ploett


Back to the top