Quanta Starts Transition to KDevelop Framework

You know it's rather easy to try too, and you will see it's not good. Take some half-finished code with errors and watch the gcc 4.x parser barf on it. Then try visualize how that can help you with code completion when writing the said code.

It is ok if you are not a developer, but just understand that what seems obvious to you is actually quite naive in actuality. Now, if I sounded hostile it is because there was a very long thread recently on kdevelop-devel that had a lot of _developers_ who were postulating the very same thing. All of them had never written or worked on a code-completion in kdevelop before.

And once again, I know you think it would 'probably worth to marry', but you would be WRONG. This is a naive belief that roughly goes:

"Hmm, we need a great C++ parser for code completion"
"Well, g++ is probably the most complete we could use"
"BINGO! That's a great idea, we should use g++!"

But, once again, this is WRONG!

The parser might be the best at parsing and compiling compilable code, but it sucks as a code completion parser. A code completion parser must be able to parse _incomplete_ uncompilable code. And it can't just produce an error and stop. Think about it...

In short, the g++ parser would have to be so heavily modified that it would lose the advantage of sharing code with the gnu folks. It would fork and diverge. Not only that, but the actual g++ parser would be a pain to retarget and modify -- and yes, I've looked and have actually hacked on both g++ and kdevelop's code completion and parser.

I don't know of any plans to do a parser like you describe. Parsers are tedious and involved code that takes a lot of time and debugging. As far as providing better error messages I think your example shows how much more complex it really is. For a relevent changed method message you would need persistant memory of changes for both files which would be like incorporating a revision system into a parser. It's an interesting idea, but parsers have to process so much data optimization is a key factor and making them revision aware would likely be a nightmare and slow. A more ideal system would be to offer the option to find and change the relevent method calls in the project or put them in an edit queue. My preference in adding automation is that it actively seeks to reduce errors.

BTW I am not aware of everything going on with the KDevelop parser, just what we've been doing with Quanta so far. That's the perspective I'm looking at. It will be exciting to review using their parser in places or possible integration and modular parsing concepts. We will have inherent differences as well as similarities.

'..but if the parser remembered that the old method used to exist it could make many simplifying assumptions'

You really talking about code refactoring here, where the IDE has parsed the source and formed an 'Abstract Syntax Tree' and symbol table of what the names used in the program code mean. Then because it knows about the structure of the code, and not just the correctness of the surface syntax, you could specify refactoring rules to transform the AST. For instance, you could add some text before or after a node, or you could move a node to another part of tree. Moving a method to another class, or renaming a method and fixing up all references to it in the code are examples of refactoring. The new parser generator and language parsers for KDevelop 4.0 will be able to use a common refactoring engine, which will work with ruby just as well as C++.

If a syntax checker was giving you errors based on what the code looked like 5 or 10 minutes ago it would just be really annoying, and feel more like the editor had only half saved your work. There's no way it would be possible to 'read you mind' to find out what you were intending to do. Hence, the need to work at a higher level than typing in lines of text, like using a refactoring engine.

Yes, that is a problem. The reason it starts the ruby code via a C++ stub is that it would be exactly the same whether it was a KPart project or a kicker applet. For those other project types there is no choice but to start via C++, as they have to be libraries dynamically loaded from a running KDE app.

The current automake based build system for KDE a way too complicated for ruby anyway. I think the best solution would be to have another application template with exactly the same ruby code, but using a simpler build/install system and no C++ top level stub.