Mattias Gärtner wrote:
> Zitat von Al Boldi <[EMAIL PROTECTED]>:
> > Mattias Gaertner wrote:
> > > Al Boldi <[EMAIL PROTECTED]> wrote:
> > > > Exactly right! The best feature is find declaration/implementation,
> > > > but this only works for pascal code. What is needed to make this
> > > > work for c/c++?
> > >
> > > Maybe a plugin for ctags can be written.
> >
> > Yes, that may be the easiest way. But I think we should use ctags
> > inlined, so that the index is created on-the-fly, and then fed into the
> > codetools as you open each file. Do the codetools support this?
>
> Partially.
> The codetools already support three 'languages': pascal (delphi, objfpc,
> parts of macpas, parts of tp), lfm and pascal directives.
>
> The file caches could and should be used (for speed and for integrity with
> the other IDE tools).
The problem with the caches is that they are somewhat misleading when you
start changing the code, and then forget to reindex. So doing it on-the-fly
should be much safer and faster for large trees.
> The code trees can be used (with other constants).
> Then some ctags functions should be added to the TCodeToolManager for easy
> handling.
> Finally some IDE features could use the ctags information. e.g. method
> jumping and code explorer.
> Of course ctags is a pretty simple parser and can not be used to parse
> macros correctly. And of course the file interdependencies can not be
> handled neither, as this requires a C IDE, which is not the goal of
> lazarus.
I think the least we should handle are the #include's, otherwise the
on-the-fly ctags may not work. Parsing the files for #include's should be
easy, right?
Thanks!
--
Al
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
