Summary...

[Ceniza]

You all know CodeCompletion has been announced as WIP for a long time now and there are even some posts considering a redesign and many other things. The truth is nobody has touched that code for a long time so the current plugin could be considered abandoned.

Rick was working on it but he retired (I'mn't blaming you and I wish you good luck despite our differences :wink:). eranif provided us his implementation using Ctags and SQLite but nothing else was commented about again. killerbot (IIRC) made a suggestion too and nothing else happened. Oh, and I'm sure I'm missing more people here, but that's just to give you an idea.

Some of you already know a new CodeCompletion plugin is in the way but it's still in an early stage and there's no any guarantee about anything.

We have suggested you all to stop posting more bugs and feature requests for the current plugin, but every now and then a new one arrives. As you can see it's pointless to do so.

I started coding a handcrafted C/C++ lexer for a new SourceFormatter plugin some time ago (there's a post somewhere in the forums about it). The lexer became usable in no time but I hadn't the time and motivation to code the formatter itself. It was going to be based on rules, a few files were written, I had some ideas and... that's it, nothing else happened.

A few weeks ago I was considering to write a parser using that lexer and try to extract the information that would be useful for a CodeCompletion plugin. Some information was easy to extract, some was not. I was close to hit the 1000 lines (997 IIRC) and it was becoming a nightmare and decided to check if Bison could be of any help, but that'd mean throwing away most of those 1000 lines of code, reading the documentation (it was helpful I had used ply for another project) and start over.

Well, I read the documentation, threw away the handcrafted parser and started writing productions to do the same thing using some evil tricks I didn't know Bison could do which would help me to keep the grammar "small".

Right now the current parser is a bit more than 1100 lines long, and growing, but it's a lot easier to add more and more stuff. It's also a bit slower than the handcrafted one but works a lot better. I've spent only a few days on it and it has already surpassed the handcrafted one and is working really stably.

I'm aware of many things that have been suggested and the idea is to take them into account, but right now it's more important to get something working, and working fine.

I post this just to inform you and show you "there's light after dark" (or whatever Thomas said). Please, don't suggest things by now; the time will come (of course, if the plugin advances).

A preview of how it's going is here (I knew the Exporter plugin would be useful someday ).

Oh, and before you start asking I clarify:

• The lexer is for C/C++ only and totally handcrafted.
• The parser is for C/C++ only and coded using Bison.
• The source code is under SVN control but is NOT in Code::Blocks' repository.
• The plugin as it is NOT being coded yet. It's just a lexer library, a parser library and a test plugin (its output is showed in that link) by now.
• It'll be ready when it be ready or it won't at all.

[Game_Ender]

I was all talk but you actually went out and got something impressive done.  Very nice work, its cool too see you have some basic template support going to.  Your test file looks good and once you have more template support you should really try it on some Boost and STL headers, that will be a hell of a test .  Also some wxWidgets based code, to see how it handles all those macros, expanded or not.

You called this a "library", does that mean you will be making this in such a way people could supply other parsers and lexers for other languages?

Just one more thing to bring up, this isn't related to your work so much as it is the plugin general.  What are the plans on trying to provide a general interface to this kind of information so that other code could use this?  Like class model generators and such?

[Ceniza]

Well, basic template support right now is: ignore the template but try to parse the class/struct/function anyway. I'm also skipping all preprocessing directives except #include. Function-like macros and more template support will be introduced later (it should be somehow easy thanks to Bison)

By "library" it's more like: you can use just the lexer for any other project and same for parser+lexer. It's the plugin's job to interface it with wxWidgets and provide all the CodeCompletion functionality. It's somehow similar to the way the AStyle plugin works (even though the AStyle library does everything, the plugin is just a "GUI" for it).

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

The PDF in that link shows the types being used and filled by the parser. If you can use that information to do anything else (it could be possible) then... well... you could just use it and do it

Right now it's top priority to get an usable parser soon since I only have 1 more week of vacations and the next semester will surely take most of my time.

[marfig]

I'm quiet surprised to hear that what is probably already considered a traditional feature of a programming language IDE has been treated so... leniently.

Maybe the problem is trying to do too much at once. Is there really the need to have a working code completion system or none at all, when the context is that of a nightly build release?

As I see it, more important is perhaps to have a working framework based on an already tried and tested system (borrowing from the omnifunc framework, for instance?). And then expand from there.

To see something running even if it only served, for instance, user defined function arguments (I know i'm oversimplifying), would be both a boon to the developer that would feel more encouraged to keep his work, and the user that would/could provide valuable feedback.

I'm not doubting your desire to see this through
However, it would probably help to concentrate on a serious scalable framework, add it to the nightly builds with just minimal features and then work from there.

[Ceniza]

Something I forgot to add to the first post: the plugin was first implemented by Yiannis and some time later Rick took it. Since Rick retired and Yiannis has been spending time in many other features and bug fixes, the plugin was basically abandoned (that's what I've understood so far in the time I've been here). As you can see there were many proposals but nobody really started coding anything.

I'm just finishing the first working version of the parser. CodeCompletion as it hasn't been considered yet, but surely it's the next part. Only when we get something, even barely useful, working we'll have the chance to provide it somehow. There's no use to provide what's implemented so far in the meanwhile and maybe no even use to provide a link to the repository

[TDragon]

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

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

[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

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

It still needs a lot of work to do all the things the current CodeCompletion plugin does (except crashing ) 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.