Re: [anjuta-devel] The new parser-engine Plugin

[Abderrahim Kitouni <a kitouni gmail com>]

Hello Moritz,

I think it is best to discuss the interfaces and their relationship here
on the mailing list rather than just give pointers to your code. This
way, it will be easier for other developers to help.

(sorry, this is going to be long, but I'd like to understand this well
to be able to discuss more effectively)

I'll try to summarize what I understood from what you've done, correct
me if I'm wrong:

AFAICT, you've added two interfaces: IAnjutaProviderAssist and
IAnjutaCalltipProvider.

The first seems to me as just a wrapper to IAnjutaProvider, why? Why not
just modify IAnjutaProvider to do what you want?

Something else I asked about some time ago was how all these pieces fit
together? What should a language support plugin do in its "activate"
method? Currently, a plugin does mainly two things:

1. register a watch on the current document
2. do whatever is needed for initializing the plugin

and the main actions are done in the current document watch: when a
document is opened, the plugin checks whether it implements some
interfaces, and registers whatever needs to be done, for example the
vala plugins does:
1. if the document is an IAnjutaEditorAssist, register an
IAnjutaProvider (for providing autocompletion)
2. if the document is an IAnjutaEditorTip, connect to the char_added
signal to provide calltips when the user types a parenthesis.
3. if the document is an IAnjuta.FileSavable, connect to the saved
signal to reparse the document (this could probably be done more often
but that's not very important).
4. if the document is an IAnjuta.EditorGladeSignal, connect to the
appropriate signals for drag and drop.

(Moritz, I just saw your other message, you already noticed this)

So the question is how a language support plugin is supposed to work
after your changes? And how are plugins are going to communicate?

An idea that just occurred to me is to have a
IAnjutaLanguageSupportManager that does the above for all language
plugins. This way, language support plugins don't need to add a watch on
the current document: all they do is to register a provider, that is, an
object implementing one or more language support interfaces (to provide
completion, calltips, etc.)

This is just an idea, and I hope other developers can provide more (and
better) ideas. I just want to stress the fact that the architecture of
the new language support plugins should be discussed publicly.

Regards,
Abderrahim