rokrau at yahoo.com
Tue Aug 21 18:36:18 UTC 2001
--- Hugo Varotto <hugo at varotto-usa.com> wrote:
> Hi Roland,
> thanks, as I said, I just did a fast port, so I cannot claim any
> What was really cool was how fast it was possible to do the port,
> Gideon's and Kate's code were very easy and straightforward to
> understand/port ( I'm still amazed about it ).
Yes, I agree, the code design is very nice.
> Couple of questions regarding ctags:
> - do you have a timeframe for doing the port of kdevelop 2.0 to
> gideon ?
No. Not yet, if you want to go ahead and do something, please dont feel
held back by me. I have very little time to work on such projects,
I was going to make the ctags support in KDevelop-2 into a kpart that
can be used with kate and/or gideon.
> - how compatible in terms of API is the kdevelop 2 ctags versus the
> ctags ?
These are completely independent implementations. I've looked at
gideons implementation and found it provides similar functionality but
it seems to be written from scratch.
> I 'm planning to start working also in a port of kats's
> "open file
> list" plugin to gideon, and I'd like to add support for displaying
> also the
> symbols that are in each of the open files. I plan to bang more on
> ctags in
> gideon tomorrow to see why it doesn't work in my machine ( most
> probably I'm
> not using it correctly ).
You probably need Exuberant Ctags from ctags.sourceforge.net.
Emacs ctags will most likely not work due to different command line
> - do you think it will be possible to have ctags as a global
> component of the
> IDE, like core(), project() or classStore() ?
I dont think that will be necessary.
> That way other
> plugins will be able to use it directly ( like the generic symbol
> browser or
> a profiling/line coverage plugin ). I'm not sure if a plugin is able
> to do
Yes, it should be, if the plugin provides an API and that is documented
> - it is possible to add support to use more than one ctgas file ? I
> the most difficult part will be doing the internal merge in the
Yes, and no, it is not difficult to do with the KDevelop-2 codebase,
dont know about gideon.
> The reason of having more than one ctags is that is nice to create a
> database for the C library, another for the java library, another for
> etc, plus one for libraries used by the project plus one for the
> itself that I'm building, etc. I used this concept with Visual
> Slickedit and
> it's very useful, specially when working with multiple programmers,
Yes, agreed, also project tag files need to be updated more constantly,
library tag files do not.
> they just exchange symbols databases for their part of the project or
> them in a common area.
Yep, that's what I would do. The KDevelop-2 code has everything needed
for multiple tags files, variable command line options and so on,
except for the UI for the ctags command. That was something I'd like to
add. Then the whole thing was going to be made into a plugin, but there
are some issues. To the best of my knowledge a plugin or kpart can not
really modify, e.g. a popup menu (the thing that shows when you right
click in KDevelop over a text token), so this doesn't really make all
that much sense any longer. The ctags code in KDevelop was written to
provide the "Goto Definition/Declaration" functionality from MS-Studio,
that's the whole point. I've given some thought to this recently, I
think ctags alone doesn't cut it really. VC uses a browse database,
which, I believe is some compiler or debugger output of all functions,
classes methods etc. that can be updated in a flexible manner plus some
tags based fast searching method. gcc's XML output should do that, in
the meantime a browse file could be generated with doxygen's XML output
and be tagged thereafter. That's what I would do if I's start it from
scratch. The parsing of all project files everytime you start
KDevelop/gideon is a "royal pain in the ass" and completely
In the garage of life there are mechanics and
there are drivers. Mechanics wanted!
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
More information about the KDevelop-devel