Re: [anjuta-devel] Vala and the new code-assistance architecture

[Moritz Lüdecke <ritze skweez net>]

Hello Abderrahim,

On Tue, 05 Jun 2012 22:31:12 +0100, Abderrahim Kitouni wrote:
> Hi Moritz, all,
>
> (sorry if I'm sounding a bit harsh, I sound like that when I don't
> understand what's going on)
No problem.

> I've been very busy for the last few weeks and couldn't follow all 
> the
> discussions about the new architecture for the language-support 
> plugins,
> I've seen Moritz's blog post [1] and repository [2], but I can't seem 
> to
> understand the the overall architecture (and I'm afraid some things 
> got
> lost in the split).
>
> IMHO, the development shouldn't start by splitting all the plugins 
> (and
> I still don't understand the reasoning behind the split), but rather 
> by
> writing the "language support interface" and the "completion engine
> adapter" and converting one plugin in the process (so you could 
> easily
> adapt for changes), and convert the rest of the plugins once things
> start to stabilize.
>
> I'm also not sure what you're trying to achieve by splitting the 
> plugins
> like that (into language-support + parser), but I think it's wrong to 
> do
> it for all plugins because (1) the language-support should be able to
> access the low-level part of the parser (after all, it's for the same
> language) and (2) the two plugins should be loaded together anyway, 
> so
> there is really no need to split them. Of course, if we want to have 
> two
> plugins for C (one using clang, and the other using ctags), we need 
> to
> split the generic C support code from the parser-specific code, but I
> don't think we have to do it for all the languages.
>
> In short, I'd like to understand on what basis are you trying to 
> split
> the plugins (that is, what should remain in language-support, and 
> what
> should be in the parser plugin) and why you think this is necessary 
> (and
> of course the relation to the vala plugin).

My point of view is the same as your. One plugin for one language and a 
new plugin for clang. I mentioned this already in the mailing list, but 
the consensus was to split the language-support plugins. At least I 
perceived it so.

At the beginning I could appreciate it bad how much code we can merge 
with this work. At the moment I can say, it's not much.

The vala plugin uses the settings of the cpp-java plugin including 
preferences widget. So the vala plugin is dependent on the cpp-java 
plugin. The vala plugin won't work without the cpp-java plugin or the 
user cannot change his settings, because the preferences widget is gone 
with the cpp-java plugin. The python plugin has nearly the same options, 
so we can merge the preferences widget of these three plugins (cpp-java, 
vala, python).

My plan is to move each parser in a separate plugin. If this works, 
I'll merge the completion code in an extra plugin. During my work I saw 
that all plugins have an assistant part and this part is in my opinion 
the best place to begin with merging the parser part.

I recognised that the new cpp-java plugin and the parser plugin are 
independently of each other.

All in all my work on cpp-java plugin was not in vain.

> I hope this makes sense.
Me too. ;-)
> Regards,
> Abderrahim
>
> [1] 
> http://skweez.net/status-report-the-new-completion-engine-adapter/
> [2] https://github.com/ritze/anjuta-clang/commits/parser

Regards,
Moritz