c++ code completion status report

[Thomas Schilling]

> > > I'd even go further: Why parsing the files over and over to do code
> > > completion instead of doing an incremental parse, that is to say: look
> > > what changed and change the internal representation of the c code
> > > accordingly. That way code completion code be sped up from maybe 30
> > > seconds to about one. I reckon, however, that this is much more
complex.
> >
> > I think that there's another 'problem': The editor has to *tell* the
parser
> > where the code has changed. And for this we would need an additional
> > interface within the KTextEditor interface.
> Than make a sample interface and send it too me, will include it in
kdelibs if
> it is generic enough ;)

Hold! The problem is a different. Creating an incremental parser is
the problem. Hav you just the faintest idea of how such a parser should
work? And even if so, have you any idea of how complex the C++ syntax is?
Since I'm the one who's doing the parser I have to dissuade from such
features.

> > > Maybe we'd be able to use the internal representation of gcc, or
access
> > > it through a well defined interface to avoid having to struggle with
> > > bison, flex and the c preprocessor at all. If we adopted that
approach,
> > > the incremental parsing would become a feature of gcc and other IDE's
> > > would be able to use it as well.
> >
> > Hmmm, I don't think that GCC is the right way to go. What will people
do,
> > who want to use other compilers then those in the GNU Compiler
Collection?
> > Okay, we could insert a *compiler code completion interface* or
something
> > like that.

That's not the point. If we compile it once it's 'our' code. i.e. we won't
be
possible to use it as a service (AFAIK). But there's some other problem:
the gcc could be confused by earlier errors. But the cc parser tries to find
out as few as possible to be error-resistant. The only chance i see is to
use the gcc's grammar to avoid doing this on our own, but it will also be
not that easy.

Thomas