Multiple tag files patch

[Adam Treat]

It can stay around, but I see no reason for it to stay put as a default plugin 
for the C++ language part, at least in the future.  That said, the 
replacement hasn't been developed so maybe we can have this argument when it 
has been developed...  I'm just foreshadowing the argument we're likely to 
have about which plugins should be moved to an 'extragear' plugins module...

On Tuesday 18 October 2005 3:31 am, Jens Dagerbo wrote:
> 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.

-- 
I'm running a Marathon in December!
HELP ME SAVE LIVES and Donate Today!
http://helpmesavelives.blogspot.com/