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

First attempt at redesign (Game Ender's idea)

(1/1)

rickg22:
Game Ender: I created this thread so we can start discussing your idea to redesign code completion. Feel free to post :)

Game_Ender:
First I have to say I like the new forum look.  I have been looking at two goals in a codecompletion redesign, a plugable parser module and exposing the parser through the SDK.  Having a plugable parser would mean you could load different parsers at run time to add support for additional languages.  This means third parties could implement a python parser, java parser, or ruby parser and just drop it in.  This combined with the greater flexibility that the compiler plugin redesign should bring will make it easier to add support for entierly different language to Codeblocks.

The other major goal is to make the parser more general and accessible through the SDK.  This would allow the easier design of plugins that have a closer relationship with the source.  Like a refactorer, a UML designer, or give wxSmith easier management of user created and generated code.  One way I have scene this done is the way Ogre does it with scene managers.  There is an abstract scene manager interface fulfilled at run time by pluggable scene managers.  The issue I am still working on, is it possible to come up with a general parser interface that makes provides enough functionality to be worthwhile or do need access to the AST in order to get any real work done.

Note: some of the above was probably said in the requirements for a new parser thread, I will give it a close look and throw some updates in here.

rickg22:
That seems an interesting idea. Right now i'm working on the optimization of the Class Browser creation. As I go on, i'll try to separate the parser into its own class.

It'll be like this:

parser -> Spawns: parserthread -> will link to: parser_module.

The parser module will parse a buffer according to certain rules, and return a Token. More or less like this:

Token* token = 0;
while(!testdestroy() && m_parsermodule->GetNextToken(token))
{
  (do stuff with token, insert it into the tree, etc.)
  token = 0;
}

And that's about it. This means the parser module will have to be a state machine, and return the token data. What do you think?

Navigation

[0] Message Index