ctags one more...

[Roland Krause]

Richard,

--- Richard Dale <Richard_Dale at tipitina.demon.co.uk> wrote:
> But we have an excellent class parser, which handles "Goto
> Definition/Declaration" perfectly well. 

??? So then let me rant a bit :-) 
>From a users point of view, the way "Goto Declartion/Definition" is
available in the current version (KDEVELOP_1_4) sucks! 

These edit fields in the tool bar are a useless duplication of
functinality alread available in the class browser! On top of that, the
completion business makes them *extremely* slow, sometimes kdevelop
seems to literally hang for multiple seconds. Dont know whos fault that
is but sometimes I thing the completion classes dont reallt scale very
well. Please edit kdevelop in itself to see this. 

What I would need is interactively jumping through code upon RMC just
as it is in VC6. If I already know the class I am in I might as well go
to the class browser and open the file myself. But most of the time, I
dont care what class I am in, I am just searching for something and
following tags through the code. It has to be fast. 

Ctags doesnt care whether you're in a class or a struct or whatever. 
> I measured the performance of
> the
> KDevelop parser vs. the ctags one the other day, and KDevelop is
> faster. I
> later commented out the QDom insertion code in KDEStudio, and it took
> 6s to
> open a project instead of 7s (KDevelop 3.0 took 4s). 

Ok, but we are talking about nonlinear data structures here so you need
to say what you opened and how it scales with N. Essentially we are
talking tree vs. hash table insertion, right? 


> I compared how long KDevelop 2.0 took to open its own project,
> compared with
> KDevelop 3.0; they both took the same time 15s.

Hmmm, that may well be, arent they using the same class parser?
Shouldnt be such a surprise then. Still, for me this is >> 45s at home
on my PII 300. I didnt think I had such an old box. Same on the SPARC
btw.. 

> KDevelop handles classes, methods, functions, variables, structs in
> C, C++,
> Objective-C and Java. 
> 
> ctags has support for Fortran and Eiffel, which we would get in
> return for
> losing Objective-C, the native language of Apple's Cocoa on Mac OS X.
> I think
> that is a poor trade-off. I've just successfully ported ctags 3.2 to
> KDEStudio,
> so I can confirm that there are no technical problems to replacing
> the parser in
> KDevelop, but I can't see any reason why we should.

I dont say that we should, all I said was, that I would like ctags
support, so I will hack it in. I also said, we *could* think of
replacing the parser code for reasons of speed and that wasnt even my
idea, I am really not that smart, I think it was John who brought it up
but it makes much sense to me. 

I dont know any Objective C, is it very different from C++? 

Roland
PS: 

>From the ctags homepage: 

Version 5.0.1 [15 April 2001]: Now supports the following languages:

Assembler, AWK, ASP, BETA, Bourne/Korn/Zsh Shell, C, C++, COBOL,
Eiffel, Fortran, Java, Lisp, Make, Pascal, Perl, PHP, Python, REXX,
Ruby, S-Lang, Scheme, Tcl, and Vim.



=====
--
Roland Krause
In the garage of life there are mechanics and 
there are drivers. Mechanics wanted!

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

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