Re: [anjuta-devel] Code assistance plugin

[Sébastien Granjoux <seb sfo free fr>]

Hi Massimo,


Le 16/04/2012 20:11, Massimo Cora' a écrit :
> while on the completion side I agree with the adoption on clang,

I'm agree that using clang would be useful too.


> maybe
> directly in language-support-cpp-java (btw: why do we leave java in the
> plugin name if we neither support the completion?), I'm not that sure
> about the gtk-tree and symbols inheritances.

I think we can make a different java plugin. But I think it would be 
better to move clang support in its own plugin so perhaps we can keep 
this plugin for both C and java.

I think the python support using rope would be better in its own plugin, 
so we use it not only for completion but for listing all symbols too, 
like what we have now for C.


> If I were able to compile that gedit plugin (please add stricter
> configure rules for the requested libraries)

I have been able to compile it. I have used libgee 0.6 and I have 
compiled the version 0.1.13, the master version was not working and gave 
me the error message that you have reported.

My system is so old that I recompile most libraries from source (gtk+3, 
gedit, cairo...)


> I would try to understand
> if clang supports also a 'ctags symbol scanning feature'.
> There's also the global-packages thing: is clang able to process a .c
> file, output the list of symbols, write them on a file and reload them
> when requested?

I think clang can list all symbols of a file. I don't think it is able 
to write them on a file and reload them automatically though because 
basically it is just a piece of a C compiler.

By example, contrary to ctags you need to provide it all C compiler 
command line options (include path, define....)

There is the same issue with the rope library used for python.

I think keeping the symbol database is still useful. At least I would 
like that we define some new interface in order to be able to use clang, 
ctags or something else to provide the same features (auto completion, 
displaying symbol list...)

Perhaps we can get something like:
* All language support plugin calls the symbol-db plugin.
* The symbol-db plugin contains only the database management and some 
interface for listing and searching a symbol. It uses some various 
parser plugins for each language
* For C, we can have a parser plugin using ctags or a parser plugin 
using clang.

But perhaps the database is really not needed for clang, so in this case 
the symbol-db plugin could keep only the GUI and the database management 
is pushed in the parser plugin using ctags. I don't know.

This is the topic of this year GSoC, so it would be useful to have a 
clear idea of the architecture. Could you propose something?

By the way Moritz and Mihai, you can participate to the discussion, as 
you see there are no specialist of clang here.


Regards,

Sébastien