Re: [anjuta-devel] Code assistance plugin

[Abderrahim Kitouni <a kitouni gmail com>]

Hello,

                  في ج، 27-04-2012 عند 16:19 +0200 ، كتب Moritz Lüdecke:
> Hello everybody,
>
> I read the previous mails again and made a little summary:
> * It seems to make more sens to write a new clang plugin for anjuta, 
> oriented on gedit plugin. After this work we can maybe merge the two 
> plugins.

As Johannes pointed out, it will be difficult to merge two codebases. If
you think we should have a common part between the two plugins, you
should be working on that first.

As for having a common part with the gedit plugin: The main gedit plugin
(gcp) is just a framework for an IDE, and we have some of its features
in anjuta already. What's really missing is a common framework for
language specific plugins (backends) and I'm not sure this is really a
good idea.

So, what could be shared with the gedit plugin? I'm afraid not much. I
think you can share more with the current Vala plugin (and improve it in
the process) than with gedit plugin. (however the C backend could be
useful to see how to use libclang). The question that remains is whether
the plugin will be written in C or Vala.

> * libclang should be optional for anjuta. If not available: use ctags
> * We have to split symbol-db (At the end of this mail I made a little 
> sketch to this point):
> > * 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.

>    * As I mentioned we can symbol-db handle like a adapter pattern, 
> which loads the needed plugins and rules for the accordingly language.

There is already a mechanism for loading the appropriate plugins for
each language. You may need to improve it a bit, but it should be fine.

> * The language-support plugins push the symbols to the symbol-db. If no 
> language plugin is available, than symbol-db will use ctags.

I think the ctags plugin could be seen as a fallback language plugin, to
be used by languages that don't have a specific plugin. As the list of
these languages could include C (when clang is not available) the
support should be relatively good (at least for C).

> * language-support-cpp-java:
> > 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)

I think this could be well the first thing to do: split the plugin into
c-style-indent and language-support-c(pp) (is there any support for java
besides indentation?). Then somehow deactivate the language-support-cpp
as you work on your new plugin.


I'm not sure what's the best architecture for this but I think it's
important to have some idea about it before starting the implementation.

Regards,
Abderrahim