Re: [anjuta-devel] Code assistance plugin



Hi Massimo!

Regarding the pdf I would split up the language-support-plugins in an
indentation part (indent-c-style, indent-python) and the support part.
This will clean up the architecture a lot I think - and it is a good
starting task for Moritz.

Regards,
Johannes

Am Montag, den 30.04.2012, 18:57 +0200 schrieb Massimo Cora':
Hi,

I've attached a pdf with a schema of the (new) architecture as I see it.
Suggestions are welcome.


Regards,
Massimo


On 04/30/2012 05:30 PM, Massimo Cora' wrote:
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


_______________________________________________
anjuta-devel-list mailing list
anjuta-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/anjuta-devel-list

_______________________________________________
anjuta-devel-list mailing list
anjuta-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/anjuta-devel-list

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]