Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign

Summary...

<< < (2/2)

TDragon:

--- Quote from: Ceniza on July 21, 2006, 08:48:47 pm ---Another idea could be to provide a third library with a well-defined interface that implements CodeCompletion as it, something like a pluggable CodeCompletion (a plugin with its own plugins). This way anyone could write his/her own lexer+parser and implement the CodeCompletion interface. Now the plugin would become a "GUI" and a plugin manager. It's an idea I just made up which requires further thinking :P

--- End quote ---

I think it's a good one. This plugin spec could be based on file extensions (or some other sort of type information); a plugin would register itself for a specific file type or types and the main CC plugin would notify it to parse the files as necessary and query it for data when code completion is requested.

Ceniza:
Yep, it could be based on file extensions. Checking omnifunc should give us some advice too :)

BTW, I just added the output of parsing basic_string.h to that site. It's working nicely so far for something that ignores template information :D

[edit]
I found many problems when parsing basic_string.h but it's good because I can find the cause and solve it, or try to :)

I fixed a few things yesterday but right now I'm feeling a bit sick and don't feel like debugging those productions right now :(

I hope to get better in one or two days so I can continue working on that.
[/edit]

Ceniza:
"A bit sick" became something worse :(... but now I feel better :D

Anyway, I just uploaded a new result of parsing basic_string.h and things look better now :D

It still needs a lot of work to do all the things the current CodeCompletion plugin does (except crashing :P) but some initial implementation of the plugin as it could begin, but if I understood correctly that wouldn't be my job :wink:

The PDF shows at the end a few important things missing in the current implementation.

Navigation

[0] Message Index

[*] Previous page