Re: [anjuta-devel] How to get the type of member that is a pointer using symbol-db

[Massimo Cora' <maxcvs email it>]

Hi Seb,

On 07/31/2013 10:49 PM, Sébastien Granjoux wrote:
> I would prefer to keep ctags, it is still working and has no replacement
> for some languages.

ok

> > 1. Does it support static symbol listing in a ctags fashion? If yes
> > we'll be safe.
>
> I don't think so. clang is a compiler, you need to know all compiler
> options like include paths, define and so on.

well, after a quick search I found 
https://github.com/drothlis/clang-ctags that could do the trick.
Maybe it's not yet stable but it could work enough good.

> > 2. The point 1 can be done fast? So fast that we can consider it nearly
> > real-time?
>
> I think clang is quite fast and several projects use it directly. Now we
> already have all the code to keep a database of symbols, so I think it's
> better to keep it. Even if I think it's not a problem to get all symbol
> of one file using clang directly. I think a symbol database can be still
> useful.

ok

> > 3. The completion. I'm sure I've seen a clang api that list the
> > suggestions given a text-file and a column-row parameters - we could
> > trash cxx-parser and swap it with the clang beast.
>
> I think it's the most common use of clang but doesn't need to be related
> to the symbol database. Currently, in Python at least, there is no link
> with the symbol database.

indeed, we can use it without the symbol-db.

> > 4. Other languages than C/C++. Well, is it worth keeping the old
> > fashioned ctags to have a really tiny support for some symbols here and
> > there in the source files?
>
> I'm interested to have symbol support for other languages than C/C++ and
> I think using the symbol database is useful in this case. But it doesn't
> need to use ctags.

ok. For the C/C++ part anyway we still have lacking features like having 
info about pointers.

> I think we could split the current symbol db plugin in two. Keep the
> current database management function in the symbol db plugin and move
> the current code using ctags in another plugin with its own interface.
> Then we can try to replace the ctags plugin with another one, using
> clang by example without changing symbol db plugin.
>
> What do you think?

it's doable, but before starting the work I'd like to have more info on 
clang and to know if it supports an output similar to ctags.
Maybe the above link could be a good starting point.

Regards,
Massimo