Code-Completion

David Nolden david.nolden.kdevelop at art-master.de
Wed May 3 17:04:06 UTC 2006


Am Montag, 1. Mai 2006 23:52 schrieb Jens Dagerbo:
>
> Sounds very cool. Did you manage to acquire SVN access?

The guy asked me for my ssh-key and told me which user-name he would choose, I 
send it, and didn`t hear from him since that. Maybe the account is open, I 
stilll have to try it out, it seemed a bit complicated. :)

Btw. In which state should I upload the stuff? Should I wait until it`s 
perfect?

> Perhaps it's my lacking imagination, but what would you do in the main
> thread while doing CC lookup in the work thread? Any additional typing
> would invalidate the running lookup and potentially cause a new one. The
> only thing I can think of that you might want is the ability to stop the CC
> work if it's taking too long - but this shouldn't happen. If code
> completion regularly takes more than a few seconds people will undoubtedly
> stop using it. What kind of computation times are we talking about?
>

I`m talking about completion-times of max. 500 ms(usually much less, depends 
on the class being completed and on how complex the types in`s 
function-signatures are), but it never feels good when the GUI is blocked, 
even if it`s just for a short period. Also, the automatic completion is not 
usable with the completion running in the main thread. 

> Much as I hate to put in more options, if the template code completion ends
> up adding alot of time to CC lookup, perhaps we should make it optional.
> This is a bad idea in general, but since the usability of the feature will
> vary with the machine spec, I think it makes sense in this case.
>

What should really be optional is if all types shown in the completion-box 
should be template processed. In a complex class like a STL-container, that 
might take some time on a slow machine.. also maybe an option should be added 
how deep the processing should go, e.g how many recursive typedefs/templates 
to resolve as maximum on a single type.


David




More information about the KDevelop-devel mailing list