Re: [anjuta-devel] Code assistance plugin

[Abderrahim Kitouni <a kitouni gmail com>]

Hello,

                   في ن، 30-04-2012 عند 17:30 +0200 ، كتب Massimo Cora':
> symbol-db is currently used for:
>
> 1. displaying the current project-file symbols on the GtkTreeView.

This is definitely useful.

> 2. providing an interface to retrieve info for project _and_ global 
> symbols. See IAnjutaSymbol on libanjuta.idl

This seems to be used by a few plugins (e.g. class-inheritance), so we
need to keep it.

> 3. providing an helper interface (IAnjutaSymbolQuery) for symbol 
> completion, which is used by cpp-parser on language-support-cpp-java.

This seems to be used for completion by both -cpp-java and -js. It won't
be needed for the clang plugin, but is needed for the "fallback mode"
and for js.

> Using clang as parser library would mean to drop the cpp-parser 
> implementation on language-support-cpp-java, and the public interface 
> IAnjutaSymbolQuery, as the info of the saved symbols would only be 
> useful for the GUI (as they can be fooled by ctags regexes).

IIUC, the plan is to have an optional dependency on clang, and keep the
current code for use when clang isn't available.

> We may instead create a new plugin, a "generic completion-engine", which 
> could receive requests for C/C++/Python/Vala/etc.
> An adapter or a strategy pattern can detect which language you want the 
> completion for, and do it.
> The exchange resulting objects can be defined as a CompletionSymbol with 
> common-language fields (icon, kind, file, comments (to be displayed by a 
> completion-widget on GUI-end).

I'm not sure this is really needed now: it could be useful when some
dependencies are missing, but not much.

What I was suggesting is that since the language plugins will keep in
memory a parse tree of some part of the project (the files of the
current target for the vala plugin, and I guess the currently loaded
file for the eventual clang plugin).

Regards,
Abderrahim