Bugs, plug-ins, and autocompletion

[John R. Zedlewski]

Well, I got the graphical side of the autocompletion pretty much done,
although we should be in feature-freeze.  In the process of doing this,
however, a couple of bugs which have been mentioned here before became
really annoying.  First, inserting a new class into the KDevelop project
did NOT change the makefile.  I just had to edit it manually.  This is
probably a big enough bug that we should try to fix it before .4.1,
because it seems like the IDE actually wrote over a modified makefile once
with a bad version!  That's a real pain in the ass.  Also, we really need
to keep a simple list in memory that says which files are currently
"dirty".  Then, when you hit "make", it should prompt you to save these
files first.  Many times, I used make, having thought a file was saved,
only to have to go through the whole build process again a minute later.
This could really confuse and annoy somebody new coming to KDev for the
first time.
I also started thinking about the possibilities of a plug-in architecture.
As it stands, the interfaces for KWrite, KWriteDoc, KWriteView, and even
CEditWidget aren't really designed for extensibility.  We should be able
to easy install a plug-in and have it either set up as a new menu item or
an event filter (autocompletion is an event filter on the KWriteView).
Then the plug-in should be able to obtain whatever data it needs from
public accessors, or perhaps a PluginManager class that acts as an
intermediary.  This includes: the location of the cursor in both col/row
and x,y coordinated, the text at an arbitrary location (including reading 
by one word at a time), the parsing of the current class, and a pointer to
a parent widget (so it can pop up menus, etc).  It also needs to be able
to insert a string at an arbitrary location, add new documentation, and
respond to a menu control (autocomplete doesn't need all this, but others
will). Currently, most of this functionality exists in protected methods
with highly variable interfaces.  It would be nice if we could eventually
move this all over to KOM/OP in the spirit of KDE2.0.  Then we can throw
in all these things people ask for, like, say, GTK-- support, though
plug-ins, and the authors won't need to gain a knowledge of the inner
workings of Kdev.  
So what do y'all think?  
--JZ