CC plugin interface redesign

[Alpha]

What is the difference between a calltip and a tooltip?

Not much, really. [...]

Correction: inside CC, calltips take multiple more steps to calculate, where as tooltips only display the full symbol below the mouse.

[oBFusCATed]

So, if I see it right, the CC plugins should only implement the GetCalltipsAt() and GetFullSymbolAt() virtual functions and then the CCManager should decide what to show.
I don't think you need 3 functions, when you can get with 2. GetFullSymbolAt could return a struct probably containing a type and visibility flags.

[dmoore]

Nice to see this is finally happening. Keep up the good work, guys! I am keeping an eye on this thread. When this is done, will I be able use my python CC plugin (after I port it to the new API) alongside the C/C++ CC plugin sharing the same UI?

[oBFusCATed]

dmoore:
Hopefully you'll be able to do it.
I suppose it will be good if we can try to port your plugin after some works is done in order to provide some real feedback to the usefulness of the API.

[MortenMacFly]

Interesting to see this discussion.

From my point of view: Make sure its also interface-compatible to Erans CC works. We shouldn't re-invent the wheel another time.

[oBFusCATed]

Someone should spend some time to write a plugin that utilizes his code.

[Alpha]

I don't think you need 3 functions, when you can get with 2.

Yes.

When this is done, will I be able use my python CC plugin (after I port it to the new API) alongside the C/C++ CC plugin sharing the same UI?

That is the plan; to allow multiple CC plugins to easily coexist.

Make sure its also interface-compatible to Erans CC works.

Has anyone yet read into the source of his CC, and could give me some pointers?  My priority is still mainly on converting the interface/CC plugin within Code::Blocks, but if time allows, I will look into that as well.

Also, people that have used alternate code completion plugins for Code::Blocks (Python, Fortran), do you have any tips as to what components I should be aware of?

Slightly less related: if I have code such as:

Code Select Expand


int foo = 1;
int MyClass::MyFunction()
{
    int bar = 4;
    MyInheritedFunction(bar);
}

If I click on foo so my cursor is outside of MyFunction(), hovering the mouse over MyInheritedFunction() usually fails to bring up a tooltip (due to failed lookup of the symbol).  However, it (almost) always works if my cursor is, for example, on bar.
Ideas why?

(By the way, I have committed step one of calltips to my repo; if nothing else, it at least eliminates the annoying multiple blank lines in a row problem.)

[MortenMacFly]

Has anyone yet read into the source of his CC, and could give me some pointers?  My priority is still mainly on converting the interface/CC plugin within Code::Blocks, but if time allows, I will look into that as well.

Last time I was in touch with Eran he pointed me to a test utility that covered all features you need to drive the CC engine. That was a good starting point for me, hence I need to look up the current sources to tell you the name again. Since Eran switched to GIT I did not follow the CC part any longer.

I could provide you with the core of the plugin I had started several times ago - not much, really, but it may point you into the direction. It doesn't compile anymore, since Eran also changed the dependencies and required libs since then... Send me an email address as PM and I can give you the sources.

[Alpha]

I have replaced GetToolTips() with:

Code Select Expand


struct CCToken
{
    CCToken(int _id, const wxString& dispNm) : id(_id), displayName(dispNm) {}
    int id;
    wxString displayName;
};
virtual std::vector<CCToken> GetTokenAt(int pos, cbEditor* ed) = 0;

I will add more fields to CCToken as they become needed.

If I click on foo so my cursor is outside of MyFunction(), hovering the mouse over MyInheritedFunction() usually fails to bring up a tooltip (due to failed lookup of the symbol).  However, it (almost) always works if my cursor is, for example, on bar.

Fixed.

[oBFusCATed]

Fixed.

I'm a bit worried that you're mixing CC interface changes with CC parser changes. Could you commit the parser fixes to the master branch/svn?

[Alpha]

Could you commit the parser fixes to the master branch/svn?

Okay.
Unrelated changes will remain isolated in the future.

[ollydbg]

Also every method that is using active editor need boilerplate code something like this;

Code Select Expand


    cbEditor* editor = Manager::Get()->GetEditorManager()->GetBuiltinActiveEditor();
    if (!editor)
        return;

    if (IsProviderFor(editor))
    {
          //Do stuff probably involving further indirection to cbStyledTextCtrl.
    }

Pass a viable and healthy editor and save the plugin developer from some suffering.

Currently, CC just register normal CodeblocksEvent (like project loaded, editor opened) and wxScintilla Events(SCI editor change, SCI editor update...), adding a layer of CCManager is a good idea, thus:

The old way is:

Code Select Expand


            +-----------------------+                +-----------+
            |                       +--------------->| CC1       |
            |                       +                +-----------+
            |    CodeBlocks Core    |                +-----------+
            |                       +--------------->| CC2       |
            |    Scintilla Core     |                +-----------+
            |                       |                +-----------+
            |                       +--------------->| CC3       |
            +-----------------------+                +-----------+


Becomes

Code Select Expand


    +-----------------------+        +---------+     +-----------+
    |                       +------->|         +---->| CC1       |
    |                       +        |         |     +-----------+
    |    CodeBlocks Core    |        |CCManager|     +-----------+
    |                       +------->|         +---->| CC2       |
    |    Scintilla Core     |        |         |     +-----------+
    |                       |        |         |     +-----------+
    |                       +------->|         +---->| CC3       |
    +-----------------------+        +---------+     +-----------+


There, CCManager can send valid build-in editor messages.

Mostly, the Parser/Parserthread/Tokenizer class should only have non-GUI things, but if you look at currently trunk code, you will see some GUI stuffs, like:

Code Select Expand

BrowserOptions       m_BrowserOptions;

BTW: the logic of the NativeParser and Parser is quite complex, and I can't understand all. (one step is what I wrote here: The parsing flow explanation by a simple example, but far from complete)

[ToApolytoXaos]

I was always curious about how Code::Block autocompletion mechanism really works and it seems this thread is the most appropriate. I have tried to read the codecompletion code and could not find where exactly caching is happening.

Is is it in the form of on an object saved in memory, in a Squirrel table, or a flat file which gets deleted upon exiting project? I have seen Pelles C using SQLite and loads remarkably fast during typing; i was really impressed by it.

Also, what is necessary to be done in order to show class / function description along with keyword auto-completion, like what other IDEs are offering?

Another thing that comes to mind. How often does it reparse a project or a file? Is it an application that runs as a background service or is the actual CC plugin that is doing so? Why not let Squirrel do so at the background and save it in a file accordingly and keep it loaded as bytecode in its VM?

[ollydbg]

I was always curious about how Code::Block autocompletion mechanism really works and it seems this thread is the most appropriate. I have tried to read the codecompletion code and could not find where exactly caching is happening.

Is is it in the form of on an object saved in memory, in a Squirrel table, or a flat file which gets deleted upon exiting project? I have seen Pelles C using SQLite and loads remarkably fast during typing; i was really impressed by it.

TokenTree object in memory, deleted on project closing. No cache on harddisk is used.

Also, what is necessary to be done in order to show class / function description along with keyword auto-completion, like what other IDEs are offering?

Mouse hover on the symbol, then there will be a tip window showing those info.

Another thing that comes to mind. How often does it reparse a project or a file? Is it an application that runs as a background service or is the actual CC plugin that is doing so? Why not let Squirrel do so at the background and save it in a file accordingly and keep it loaded as bytecode in its VM?

reparse triggered depend on user setting, e.g. user is editing on the source file/after saving the source code. Currently there is a thread pool in the CC, so parsing is done in worker thread.

I'm not sure why CC is related to Squirrel?

[oBFusCATed]

Why not let Squirrel do so at the background and save it in a file accordingly and keep it loaded as bytecode in its VM?

Wat? CC is done entirely in C++ because it is a part of the application that is performance critical. Why do you think it needs to be written in Squirrel?
There is no database, everything is stored in objects in memory. Nothing is cached on disk.

p.s. Please stay on topic. This one is related only to the API interface of a CC plugin.
       If you want to know something about CC or want to improve the parser only then start another one.
       Feature requests for CC not related to this API interface should go in another topic, too.