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