Re: [anjuta-devel] Code assistance plugin

[Massimo Cora' <maxcvs email it>]

Hi,

On 04/22/2012 11:44 PM, Abderrahim Kitouni wrote:
> 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?


symbol-db is currently used for:

1. displaying the current project-file symbols on the GtkTreeView.
2. providing an interface to retrieve info for project _and_ global 
symbols. See IAnjutaSymbol on libanjuta.idl
3. providing an helper interface (IAnjutaSymbolQuery) for symbol 
completion, which is used by cpp-parser on language-support-cpp-java.
4. using global packages' headers files to create a cache to speed up 
the queries on the symbols.


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

I would implement clang as a separate plugin because "symbol-db", as its 
name suggests, would be only a database of symbols. At this point I 
would not implement logic there.
Its behaviour could be to provide only gtk+ symbol icons (tree, etc), 
and can work with ctags backend.

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

This seems quite elastic to be expandable in the future.

Regargs,
Massimo