Porting CTags plugin

dukju ahn dukjuahn at gmail.com
Mon Jun 11 04:48:46 UTC 2007


2007/6/11, David Nolden <david.nolden.kdevelop at art-master.de>:
> On Monday 11 June 2007 04:22:30 dukju ahn wrote:
> > Idealy, but language support can't be perfect, while CTags is perfect.
> > Think about the KDev3 language supports. The CTags can lookup
> > even macros or variable definitions, while language support can't.
>
> c++-support in kdevelop-3.4.1 can lookup macros as well as
> variable-definitions, even such that ctags cannot lookup because it only
> processes a specific directory. Also ctags cannot respect the context, so I
> don't see why ctags should be superior in any way to language support.
>
> Of course kdevelop-3.4's c++ support is limited, but I don't see where ctags
> should be superior, and kdevelop-4's c++ support will probably be a lot
> better.

Ahh, yes I overlooked the downsides of CTags, and I didn't know the
macro support in C++. Anyway, my intention was that I usually use language
support but I sometimes need CTags's aid.
Both are not competing ones for superiority, rather they can compensate
each other. But, see the bottom of this mail.

> > I useually use jump to XXX or QuickOpen part, but there is some case
> > where only Ctags is really helpful.
>
> Then we should analyze that case and see how we can solve it with our own
> system. :-)

Beacause It's just not implemented. QuickOpen opens only file/class/methods
and is perfect only for them. Searching macro is not implemented.

> > Currently, we don't have any promise that each language support
> > would be that perfect.
>
> Ok, for other languages than C++ I can see that it could become useful..

Yes. there are many language supports other than C++.

Well, then I changed my mind. It is right thing to improve language supports
, rather than reling on other tools. I'll not port it.




More information about the KDevelop-devel mailing list