Re: [anjuta-devel] Aggressivity of merging

[Moritz Lüdecke <ritze skweez net>]

Hi Abderrahim,

> > Today I tried to merge the calltip code in language-support-vala 
> > with
> > the new parser-engine plugin. Each corresponding method do this in a
> > different way. (see
> >
> > https://github.com/ritze/anjuta-clang/commit/814f11c887e63f0a4b9c71eff17649afd8b99e58#L2R401
> > "plugins/language-support-vala/provider.vala" and
> > "plugins/parser-engine/plugin.c")
>
> FWIW, the vala plugin isn't using IAnjutaSymbol, but is using 
> ValaSymbol
> (from libvala) directly. So merging isn't as straightforward as you
> might think.
>
> Regarding your IAnjutaParser interface, I think it's better to name 
> it
> something else. AFACT, it isn't supposed to be implemented by 
> individual
> parser plugins but rather to be shared among them, so the current 
> name
> is misleading.
I know. I'll change the name, when I finish with my work (and a better 
name come to my mind).

> > Additionally I couldn't find out, if the parser-engine plugin will 
> > be
> > ever append a "..." string for a parameter with variable number of
> > arguments (like args in the main method).
>
> I think the best way to know is to try it :) start anjuta and try to 
> get
> it to show calltips for known varargs functions (like printf or some 
> gtk
> functions) and if there are no ..., then it doesn't support it.
With printf calltip works now and it shows "...". Yesterday I tried 
many commands with a parameter with variable number of arguments, but 
the calltip would never work.

> > Another point is the cache part, which each language-support plugin
> > does it in a different way too.
>
> My advice is to try and come up with an interface first and try to 
> see
> how to implement it best (looking at the existing implementations) 
> and
> then try to port existing plugins to the new interface progressively.
> For example, I'd like to see what you want a language support plugin 
> to
> do when activated (in pseudocode, what would need to be implemented 
> if
> we wanted to add a new language).
>
> I'd also like to make sure I understand your diagram, so IIUC, what 
> you
> have now is: "completion engine interface" is IAnjutaParser interface
> and its implementation in the parser-engine plugin, right?
Right.

> Also, I'm not sure about how the plugins are supposed to interact
The parser-engine plugin will only loaded, if the programming language 
is C/C++, Vala, JS or Python. (But I was not sure whether I really 
should do this through a new plugin.)

> The more I think about this, the more I think it might be a good idea 
> to
> use libpeas for plugins, as that would allow for having multiple
> "extensions" (libpeas speak for classes implementing a given 
> interface)
> in the same plugin, and that would help us with the problem of 
> splitting
> plugins.
>
> What do you think of this?
I doesn't know libpeas. So I cannot assess this.

Regards,
Moritz