Re: [anjuta-devel] Code assistance plugin

[Sébastien Granjoux <seb sfo free fr>]

Hi Jesse,


Le 10/05/2012 13:08, Jesse van den Kieboom a écrit :
> Sorry for not replying earlier to this thread, I hope I can still
> provide some useful insights.

Thank for your answer, it is really interesting. I have sent several 
messages to get some reaction but there is no urgency.


> It's true that currently gcp contains the binding with
> gedit. But it also contains an infrastructure which is used to implement
> the backends, which is mostly (but not completely) independent from gedit.

I have looked a bit at gcp and it's useful to have such library. There 
isn't really such thing in Anjuta perhaps because a part is using the 
symbol-db plugin which handle all languages in the same way using ctags. 
But each language support plugin re-implement some common parts for sure.

So you think it could be changed to be completely independent of gedit 
and gtksourceview?


> Yes, and that is a shame! You should consider using libpeas :)

libpeas appears several years after the plugin system in Anjuta. I don't 
really see advantages to switch to libpeas. I'm even afraid that some 
feature will be missing.


> The way we try to manage this a bit is by slowly merging
> functionality that was developed as a plugin (because it's just much
> faster) in a library (most notably gtksourceview). This library can then
> be easily reused, given it exposes the proper API.

Using a plugin is not more difficult than a library and it is more 
flexible. By example if you merge everything in gtksourceview, we will 
have to re implement it for Scintilla.


> 1) Make it a very shallow wrapper around libclang. This can be done, but
> is it really interesting to do? If you use vala you can simply use the
> .vapi file that I wrote and you can access all the libclang API in an
> object oriented way from vala, no GObject needed. Also, there wouldn't
> be any code sharing really, the shallow bindings would not be where most
> of the work is done.

I'm agree. We can use such library without troubles but the gain is 
small, I'm even not sure it worths it. Especially because clang is 
already designed as a library, so we don't need a complex wrapper.


> 2) Make a common abstraction layer for these kind of compiler services
> which can be reused by multiple projects. This is much more interesting
> in the end, but also much more difficult to do. I think it will be
> difficult (but not impossible) to merge the ideas from Anjuta and from
> gcp into a library providing a standard API/interfaces for building and
> using language assistance. These interfaces should then be used by both
> projects.

Ok, we can try to define something like this. I'm not really working on 
it currently and I haven't write the language support part in Anjuta. I 
have started the discussion because we have one GSoC student, Moritz, 
working on it.


> Ideally, neither project would have their own abstraction
> layer on top of this library because abstractions of abstractions ==
> bad. I know Anjuta kind of likes this (i.e. having support for both
> Scintilla and GtkSourceView), but I really, really strongly feel this is
> the wrong way to go (do you like wxWidgets?).

I don't see it like this. I don't think that less abstractions is 
better, I think we need the right quantity of abstraction. If we haven't 
abstract Scintilla, the use of GtkSourceView would have been really 
difficult, it would have been a pity, no?

I'm probably the main responsible for keeping Scintilla working in 
Anjuta. I see an IDE rather as just some glue allowing you to use 
existing tools (editor, debugger, make...) in an easy way. So I think it 
makes sense. If you see GEdit as an editor around GtkSourceView, like 
SciTE for Scintilla, indeed it is less useful.


> 1) I read about rewriting parts of the gcp plugin to C, this is a _bad_
> idea. Use vala, really. It's not really worth it anymore to write these
> kinds of things in C, the boilerplate is mindboggling. vala will compile
> nicely to GObject C, you can generate a .gir for you lib and generate a
> gi typelib, then use your vala library from any introspection supported
> language.

For me, C is already a high level language. Comparing to vala, the 
additional codes is tedious but not really difficult to write. Moreover 
it is still easier to compile C than vala at least using autotools, I 
imagine debugging could be easier in C too.


> 2) Don't shun from thinking about collaborating on this. I know how this
> normally goes (I do this myself), it's much easier to just write a
> little plugin using clang to use just for Anjuta. But in the end we'll
> be maintaining two things separately. Now is the time to think about how
> to provide general compiler services for GNOME applications. Having a
> common library we could even think about writing dbus services to
> organize things globally at some point.

Ok. I think that such library should be independent of obviously Gedit 
and GtkSourceView too as it would be useful for Scintilla. Do you agree 
with this?

Currently in Anjuta, all interfaces and the related code in contained 
one library: libanjuta. We could probably add this libgcp library too.


> 3) I saw some ideas of merging the gedit and Anjuta applications. This I
> think will not really be possible.

Ok.


> 4) I've noticed some performance and memory issues with using libclang.

It looks like clang is used a lots but I have expected a much better 
documentation. I have found mainly tutorials using different version 
libclang. So I'm not surprised.


Regards,

Sébastien