Code completion and interative syntax (semantic) checking

Thomas Schilling snuffeler at
Wed Jan 23 22:37:04 UTC 2002

Hello again,

> > Dynamic syntax checking is hard. Because the C++-Syntax is extremely
> > mad. (Many ambiguities and a LL(1) would hardly suffice.)
> I don't quite agree. It all depends on how the error-token in bison is
> used. With a smart part on that side LALR(1) (which is what bision uses
> (its a subset of LR(1))

If you do it - no problem ;-)
Do you have a _complete_ C++-syntax?

I already had some experiments with the error token - but there was one
big problem: bison is bottom-up so if you build up a tree (of nodes
holding operators or other tokens) and an error occurs you will have some
left-alone nodes that can be destroyed by nobody. (they have no parent)
I didn't found a solution, yet.  (But actually i didn't try much more.
currently i'm trying to integrate the template and typedef-stuff to the CS.)

> > exa is working on making a library out of sourcenav (a code browsing
> > tool by RedHat) but I'm afraid it wouldn't be that useful for CC.
> why?
see victor's mail -> the class-store (i guess - or better ask
exa = Eray Ozr... can't spell it, see the mailing list)

> > I would find it best to have it in an independent library so also
> > tools can use it.
> that doesn't contradict. We may do a seperate library but for KDE to be
> useful, there should be KTextEditor interface for that library. And _them_
> Gideon uses KTextEditor. That's much rather how it fits together.

As you say ... :)

> > > Either a new interface would have to be designed or the text
> > > interface to be extended.
> > We have CppSupportPart (see gideon: parts/cppsuppoert )
> I don't have an overview of the architecture. It should be generic enough
> to support other languages as well. And so should our library.

WHAT? Wow. What a big plan, eh. That will be really hard!

Ok, so tell how's your idea of doing this. I think it's very language

Or... do you mean just the interface? <:-|
We already have somthing like this (but i think it can be improved)
see the code. or see:

> > I once started the approach to have a two-component CC:
> > part one is the parser that builds up a tree and
> > part two analyses an expression to find out it's type
> Yes. That's how I did the parser at university as well.

You already have some code ready? Goooood. Send it and we'll check it.

> The first level consists of syntax checking only. It's got the advantage
> that semantic errors don't cause an error yet. That's done in part two,
> the semantic check. Some setup are performed in the first step, however.
But ain't  "a = b."  a syntax error?

> > Both could be done in bison if you can avoid any errors (otherwise it
> > be very hard to ignore them).
> you may have errors in certain parts of the tree and the rest can still be
> OK. You just have to mark it as an error to be handled consistendtly.

And _that's_ much hard work, i guess.

> > > whole parse tree of the last few files opened in memory so that typing
> > That's for sure.
> ... but requires careful design.
I'm working on it. We also have some other problem: the CS is used also
by other languages.

> > Does anybody know wheater any of those features exist in any open source
> > IDE that we may copy from?
> I found none.
Ok. We should ask the Gnome guys if they are interested in such a library
as well. If it's independent they probably won't say no just because we're
"the bad guys".

> If you'd like to help us or just to get some more insight into my
> considerations you can simply send me a mail.
I prefer the mailing list. More people more ideas.

> (I even speak german ;-)
I don't really care. Actually for cs stuff I prefer plain English, because
I don't have to translate all the technical terms. After all which sounds

- "hacking code completion for Gideon" or
- "code completion für kdevelop hacken" ?

> P.S.: How is studying informatik at hu-berlin?
Me too! (I'm in Adlerfhof tomorrow from 15h onwards)

Gregor Zeitlinger
gregor at

Kdevelop-devel mailing list
Kdevelop-devel at

More information about the KDevelop-devel mailing list