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

[Benoit Cerrina]

On lun, 14 fév 2000, you wrote:
> 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 does sound incredibly slow, like at least 20s


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...

I think that would be a good idea


> --JRZ
-- 
Benoit Cerrina