Codecompletion bugbears

[dmoore]

I've been thinking for some time about implementing code completion support for python (or at the very least some sort of advanced symbol browsing, because in a dynamic language you can't guarantee the type of a variable until runtime). I've also recently started tinkering with a syntax checking plugin. However, I'm not sure how to get these things to play nicely with the current code completion plugin. The current CC plugin seems to be premised on it being the only such plugin to offer CC like services, as it appears to clobber any other attempts to use the calltip interface and offers code completion support no matter what language is being used (i.e. its not restricting itself to offering completion to c/c++ like languages). There's also a question of whether i should reuse the symbols tab of the management pane or create my own.

anyone have any thoughts on this? should i just give up or is there a place for broader codecompletion support?

[DrewBoo]

dmoore, if this project is possible, my programming skills are at your disposal.  I'm sure I'm not the only one who would get a lot of use out of this.

[dmoore]

good to know, Drewboo.  I'll PM you at some point

the nice thing is that a lot of the work is done on the python side, for example:

http://docs.python.org/lib/module-pyclbr.html

I've also fleshed out some backend C++ code to spawn multiple python processes and communicate with them via xmlrpc, which is a lot less messy then going down the embedded interpreter route. (I've already used that backend to embed a python interpreter in Code::Blocks, though it is still in a very rough state. You can find the source for this in the trunk/CBPythonPlugin in the cbilplugin repo on berlios -- build the experimental target)

[MortenMacFly]

The current CC plugin seems to be premised on it being the only such plugin to offer CC like services, as it appears to clobber any other attempts to use the calltip interface and offers code completion support no matter what language is being used

Amen.

As you are most likely aware there are quite some trials:

First there is a branch where rickg22 tried to refactor the current CC plugin. Unfortunately it has been dropped as Rick is now into other business.

Second there is the great work done by Ceniza which is really promising! Unfortunately he did not manage to complete all the work within it's first time frame and now he is working hard in a new job... So he basically has way less time to work on it these days.

Finally I for myself tried to use the CC framework Eranif developed (CodeLite). I have quite some work done already, but unfortunately the design of CL is not really compatible with our plugin framework. So one would need refactoring here.

So... rather than starting another trial my personal favorite is the Ceniza approach. Probably he will find the time to support (at least via email/MSN) such development.

[nanyu]

Have anyone knew "CodeLite"?   I found the "CodeCompletion " in CodeLite is no bad。

[MortenMacFly]

Have anyone knew "CodeLite"?   I found the "CodeCompletion " in CodeLite is no bad。

Finally I for myself tried to use the CC framework Eranif developed (CodeLite).

...can you read?! That was in the previous post to yours. :shock:

[Wolf]

I'm trying to fix the actual code completion plugin, but I'm facing serious design flaws. So yeah, it really needs revamping, and that should allow for more flexibility. It must know which language it is in. It actually is written for C++ only.

Code

struct BigStruct {
    struct smallStruct {
        int a;
    };

    int b;
};

struct smallStruct mySmall;

This is only accepted in C, not in C++, as I would have to use BigStruct::smallStruct. So if I try to develop a code completion compatible with C AND C++ at the same time, I'd have to add it to both BigStruct and the global namespace (which is not even recognized by CC right now).

If it were possible to have a syntax file that we could load and it would dynamically parse the code according to this syntax, all we'd have left to do is to write those syntax files, and it would support even custom languages. It could use dynamic languages for this, such as Lua or Ruby, which both integrate well in applications.

As for the symbols manager, I'd suggest a tree-like structure, just like the actual one, where the categories are customizable. This would mean the parser token types would have to be dynamic too and defined in the syntax file, along with the categories.

-- Wolf --