Issue with KDevelop: Is it using different parsers in parallell for different puropuses?

[Jakob Petsovits]

On Tuesday, 15. August 2006 20:18, Erik Sigra wrote:
> > Från: Jakob Petsovits <jpetso at gmx.at>
> > class MyClass
> > {
> >   int main()
> >   {
> >      return ((int) bla == |
> >   }
> > };
> >
> > where "|" is the cursor and you haven't finished the line yet.
> > Nevertheless,
> > Katepart highlights everything correctly, including the "return" and
> > "int" tokens which are part of a statement that can't be parsed
> > correctly.
>
> I think the code is correct until the "|" and it should be highlighted
> correctly until there. Then it is OK to highlight the following "}" and
> "};" (and the rest of the text) in red (as in syntax error), because it is
> not valid and it would be too complex to guess the meaning.

In theory, yes. In practice, we won't store such incorrect statements at all 
because the structure shouldn't contain invalid stuff, it makes everything 
harder. (At least that's how it's done for Java and C#, I think the C++ 
parser is similar in this respect.)

Also, the parser has to know that the "}" does not belong to the statement, or 
else there'll be one closing bracket missing and everything breaks.
So, your description sounds nice, but try to do it yourself and request the 
same thing afterwards. I promise that you won't do it once you know how 
everything works.

> I know that g++ tries to parse beyond the first error, but then it has to
> guess what the  programmer meant, and it is really bad at guessing, because
> it is such a complex task. A proof of that is that error messages beyond the
> first are usually useless. Fixing the first error will "fix" the
> other "errors" as well. Seeing how bad g++ is at guessing beyond the first 
> error, I do not expect KDevelop developers to try it.

g++ does a good job, but recovering _and_ showing correct error messages is 
very hard. What you'll get from KDevelop is red highlighted lines, maybe red 
highlighted single tokens. Don't expect semantic analyzing like g++ does.

> What I expect is 100% correct highlighting of correct code. Kate gives 90%
> correct highlighting of correct and incorrect code.

I think Kate is doing much better than 90%. I'm still wondering how KDevelop's 
own parsers can be able to yield better results than the Kate ones, if it's 
not for contextual information like "I know that type, let's paint it violet 
because it's an enum".

For my part, I have yet to encounter situations where I'm discontent with 
Katepart's highlighting. (Just give me proper indentation, please!)

Highlit,
  Jakob