Re: [anjuta-devel] How to get the type of member that is a pointer using symbol-db
- From: Sébastien Granjoux <seb sfo free fr>
- To: Massimo Cora' <maxcvs email it>
- Cc: anjuta-devel-list <anjuta-devel-list gnome org>
- Subject: Re: [anjuta-devel] How to get the type of member that is a pointer using symbol-db
- Date: Wed, 31 Jul 2013 22:49:21 +0200
Hi Massimo,
Le 31/07/2013 00:53, Massimo Cora' a écrit :
IMHO I would suggest to drop ctags at all. It's too weak to have some
serious symbol parsing. Secondly, it appears to be a dead project for a
long time now - so no help from its devs.
I would prefer to keep ctags, it is still working and has no replacement
for some languages.
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.
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.
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.
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.
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?
Best Regards,
Sébastien
[
Date Prev][
Date Next] [
Thread Prev][Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]