Code completion in KDEStudio

[Richard Dale]

On Thu, 12 Apr 2001, Roland Krause wrote:
> I am working on creating and loading a ctags file for the purpose of
> having "Goto Definition" and "Goto Declaration" options (upon RMC) in
> KDevelop. 
> 
> You can probably use this code which parses the ctags file into a QDict
> based datastructure. 
> 
> I dont think that using ctags will get you a complete class tree but I
> may be wrong. 
> 
> Anyway, exuberant ctags, which I use for this purpose it *fast*, much
> faster than a compiler can ever be and it has a lot of information
> ("extensions") about classes, structures, private and public members
> and so on. I've been reading the manual back and forth a couple of
> times now and I think it may get us a good step further w/o KDEStudio
> code. 
> 
> What I do still not understand is the following: 
> 
> We already have a class parser and that class parser works pretty good.
> Why don't we use it for code completion and replace it later if
> something better comes along? 
Well, yes we have a pretty good class parser, and in Objective-C and Java for
KDevelop 3.0, not just C++ any more. I don't know about ctags Objective-C
support. I suggested ctags, before I'ld actually studied the KDEStudio code
properly. It doesn't use ctags, but it does have a header called 'ctags.h', (and
some guy in a discussion said it used that), which had sent me down the wrong
track. I like the idea of using QDom as a class store though, like KDEStudio -
it seemed to work well (although I prefer the KDevelop parser).

I'm checking out KDevelop 2.0 now, I need to look at how the gdb stuff works to
do something similar for jdb. So I'll look at how the code completion might fit
in when I do that.

> Somebody on this list pointed out that the problem is not the class
> parser but to parse the file the user is working on and then again
> someone else claimed that this was not the problem at all but the
> problem was to parse the class tree of the project fast enough. 
jbb did some profiling of the parser code a while ago - it spends most of its
time in the tokenizer. I think it's fast enough, but probably could be called
more cleverly (less often, and only for changed files or something). I'm
interested in hearing from people who have measured these things - no point in
having an opinion without doing that.

> Maybe someone should try to state the problem cleanly first. I am sure
> it is possible to solve it rapidly then. 
Well put!

-- Richard

-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«