code completion

[Benoit Cerrina]

Hi,
I definitely agree that it is needed and that its something great and frankly
what is done in those ide (as far as code completion is concerned) is far better
than anything done in vim or emacs (it hurts to say that).
Right now the problem I'd like to tackle is the scripting so I'll leave this
task to you or to someone else.  Especially since I don't have as much time as
I used to when studying now that I have a full time job a wife and a kid ;).
Ben

On ven, 14 jan 2000, you wrote:
> I started working on this issue a little while back and stopped for a
> variety of reasons (mostly including too much other work).  If nobody
> else gets too it, I certainly will this summer, and possibly this Spring
> (the current semester is a KILLER for me).  If you want to see how this
> feature would work, download the free edition of JBuilder from
> www.inprise.com/jbuilder.  Obviously, it's a Java product, but it's the
> same idea.  Once you use an IDE with code completion, it's hard to
> imagine ever going back.
>    Basically, the task requires some pretty smart parsing in order to
> work well, but it's quite doable.  There was, at some point, a plan to
> put all of the classes in the current project + all of the basic KDE/Qt
> classes into a local mini-database, so I stopped working on the
> completion until that task got completed (has that since been scrapped
> as unnecessary/too difficult?).  WsStudio (wxstudio.linuxbox.com) is the
> only free IDE I know of that has this feature, though that project seems
> pretty much halted right now, it might have some good tips.
>    Conceptually, it's not too hard, but it is a lot more complicated
> than shell completion.  To take an example, look at:
> "
> KMyDialog dlg;
> ... lots of intervening code ...
> iint doSomething() {
> 	(*((someOtherClass*)dlg.pointerToMyClass)->funcReturningPointer(x)).
> "
> Now, when the user enters that last '.', the code completion has to
> parse that whole complicated expression, find out what class (or struct,
> union, whatever) someOtherClass::funcReturningPointer() actually
> returns, and then come up with a list of all the members of that return
> type on the fly.  Of course, you can find much simpler and much more
> complex examples.
>   From what I've heard and seen, other systems do manage to parse the
> current file and (if necessary) its includes on the fly to find the type
> of the variable to the left of the '.'. '->' or '::' in question.  It
> means that a pretty fast parser is necessary if you want to handle large
> source files without an unacceptable delay.  More frustratingly, this is
> also different from (but closely related to) what the current class
> parser does, because it focuses a lot on scope and finding random
> variable declarations.  Jonas obviously knows a lot more about these
> issues than I do, though, so I could be totally off base.
>   So, basically, if you don't find anyone who can/wants to do it, I can
> promise to get to it in a few months (because I would REALLY love this
> feature, but otherwise I wish good luck to whoever steps up to do it.    
>   Keep up the amazing work, guys!
> --JRZ
-- 
Benoit Cerrina