Re: [anjuta-devel] Code assistance plugin

[Abderrahim Kitouni <a kitouni gmail com>]

Hi all,

              في ن، 16-04-2012 عند 21:46 +0200 ، كتب Sébastien Granjoux:
> 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.

FWIW, the current plugin is used by vala as well for indentation, so
splitting it into 2 plugins (one for language independent stuff like
indentation, and one for the C/C++ specific stuff that would eventually
use clang) seems like a fine idea to me.

btw, what do you think about the added dependency on clang? Should it be
optional (and what would remain if it's unavailable?) or should it be
mandatory?

> 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.

I'm not sure what you mean. IIUC, the symbol listing is currently
handled by the symbol-db plugin using ctags, do you want to make it so
that language-support plugins push the symbols to the symbol-db using
better parsers than ctags? 

> > 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.

and the same for libvala, and btw, I have some code in the Vala plugin
that tries to get the VALAFLAGS from the project, that might be
improved.

> 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.

Why? you seem to be separating the language support plugins from parser
plugins, and I don't see why the language plugins need to call
symbol-db, they might already have the needed info in memory for things
like autocompletion.

> * 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.

That might be fine, but the ctags plugin would be shared among
languages, it doesn't need to be C specific.

> 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.

I don't know what is the database used for, but if it is needed for
listing and/or searching symbols, we'd need to keep it.

> 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?

I don't know, but I think the architecture should take into account the
other plugins: the Vala plugin is doing something similar using libvala,
and having a common architecture would be a good idea.

Hope this makes sense,
Abderrahim