KDE studio has code completion-- and it's interesting

[John Zedlewski]

Well, I was browsing the KDE studio page when I saw that their newest
version has the mythical code completion feature.  Theirs requires you
to hit "CONTROL-P" after "varname->" or "varname." rather than
automatically popping up the dialog box.  (I believe IBM's VisualAge
does something similar?  Could be wrong, though.)  I don't have KDE 2
installed so I can't test out its speed, could somebody do that?
  The interesting thing is the implementation.  First, KDE Studio uses
the same classparser as KDevelop, and it even uses KWrite for its
editor, so there are a lot of similarities.  The code completion plug-in
is a really strange, but neat hack.  I'm not sure it would be suitable
for the long haul, but it's easy to implement.  
  
  First, the IDE determines the current position in the editor.  Then it
turns off the editor's updating/repainting and pastes some weird string
(they use "WAIT_STUDIO_WAIT", but it doesn't really matter) followed by
";//".  Then, it saves that file to disk.  Then, it modifies the
makefile to add a special line that just compiles the current file to
assembly, but dumps it to /dev/null.  Then it calls "undo" on the editor
to get rid of the weird string and it resets the Makefile to its
original state.  But, of course, you can't compile
"varname->WAIT_STUDIO_WAIT;//" without an error message.  So the IDE
reads the stderr of the make process and looks for the error message
that says: "`class whateverclass' has no member named
`WAIT_STUDIO_WAIT'".  But in the real output, "whateverclass" is
replaced by the actual name of the thing to the left of the current
'->', '::', or '.'.  It then calls "getClassByName" on the classparser
and fills in a little dialog box with the methods of that particular
class.
  Weird, huh?  It gets the robustness of the gcc parser, which is
definitely a big plus. But their current implementation seems to save 
over the existing file being edited (which could be very bad), although
that of course could be fixed.  The biggest concern is speed, and I
don't see how you could make this process super-fast (though you could
probably stop messing around with the makefile if you were clever about
it).  

  On the other hand, the current classparser of KDev could probably be
subclassed to do a similar thing.  Or the current grammar (which some
people say isn't working very well, though I haven't noticed a problem)
could be replaced by the actual g++ Bison grammar (
"SRCDIR/gcc/cp/parse.y").  Hmm...
--JRZ