A parsing proposal
JohnZed at aol.com
JohnZed at aol.com
Tue Jun 22 23:35:36 BST 1999
Hmm... it seems to me like we need to know the following things to do code
completion: 1) all the member variables of the current class (easy). 2) all
the member variables of its base classes (not too bad). 3) all the local
variables in the current block (a bit harder maybe?).
That gives us enouhg to identify the class to which the current object
belongs. All the classes that are already in the project have been parsed
already and are in the left tree view, so they're easy. There'll be a lot of
base classes to worry about, but many of the key ones (QObject, QFrame,
whatever) can be kept already parsed (depending on how much memory that'll
consume).
I've been wondering if we should find a way to serialize parsing info to a
file. When I boot up VC++, even if I have a helluva lot of classes, they
seem to show up almost instantly. If we could do this (and save it in the
project file or something parallel to it), then we could pre-parse all of the
QT and KDElibs files. Loading them would then be much faster and the bootup
would be greatly accelerated.
How fast is the XML parser that KOffice uses? Maybe an XM file format for
classes and methods? That would probably suck up too much disk space.
Maybe just one index file per directory that contained a series of pointers
into files?
Anyways, my immediate goal with this whole code completion thing is to get a
stupid shell ready that pops up the little frame at the appropriate location
and time, and then figures out what the . or :: operator is being applied to.
Then everybody else can play around with it and test out different parsing
ideas when they get board. I think I'll have this done in a couple of days.
I have to say, though, that if we can release a version 1.0 that is stable,
has a dialog editor, code completion, CVS integration, and a great class
browsing tree (note how many of these are already started or almost done!)
this will have to be one of the most useful KDE projects so far!
--JZ
More information about the KDevelop
mailing list