Multiple tag files patch

[Jens Dagerbo]

Yeah, we had that argument 2 years ago already. It hasn't happened yet.
Also, so far, the c++ codemodel has been geared towards producing code
completion and the class view, which is a bit different than the context
sensitive navigation of finding foo on bar.foo(). The best we currently got
is "Quick Open Method" but look at the implementation and find that it is
far from efficient.

Ctags is of course far worse, it's all about brute force and doesn't
understand C++ at all. It is however _very_ fast.

There is also the fact that Ctags supports more than C/C++. 33 languages, in
fact. At least half a dozen of which are relevant for KDevelop3. See
htttp://ctags.sourceforge.net/languages.html

There is considerable overlap between Ctags and the features that can come
from the cpp parser, but CTags:
1. works today
2. works for more than C/C++
3. is very fast
4. is quite efficient, memory and cpu-wise.

I say we keep it around a while longer.

// jens


On 10/18/05, Adam Treat <treat at kde.org> wrote:
>
> Speaking of which, a few of us were talking about the idea of getting rid
> of
> CTags altogether for the KDevelop4 branch. There really is no reason that
> the new parser can't handle this functionality. One code database really
> should be enough and the user won't need to regenerate it manually.
>
> Something to keep in mind.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20051018/62f36af1/attachment.html>