On Tue, 13 May 2014 09:54:09 +0200 Thomas Martitz kugel@rockbox.org wrote:
Am 11.05.2014 20:31, schrieb Dimitar Zhekov:
On Sat, 10 May 2014 21:56:30 +0200 Thomas Martitz kugel@rockbox.org wrote:
On Sat, 10 May 2014 14:47:17 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
+1 for some form of introspection/code generation.
Just to be clear: by "introspection", I don't mean *replacing* struct GeanyDocument with GObject GGeanyDocument and so on for the entire API. We may have a GGeanyDocument which represents (a) the GeanyDocument structure, (b) all document_*() functions as geany_document_*() and (c) all "document-" signals as "geany-document" with a GGeanyDocument argument. We can't generate signals for GGeanyDocument "fields" being changed directly from C, but we don't support such signals anyway.
That's two GeanyDocument APIs to maintain.
You don't want to maintain a mapping of GeanyDocument, but are have not problems with maintaining 5 manually written introspections for it?..
and it requires a lot of changes to Geany (doesn't it?).
It will require some changes, for example GGeanyDocument will not be straight-forward because of our organisation of the document list. Most will be additions though, with few (if any) API breaks.
So it does require non-trivial changes to the core, too?
Anything except manually written introspections for each language requires changes in the core. I suggested a way to minimize them.
GeanyPy proxy = ~150 KB. 5 language proxies = ~750 KB, code that will have to be written and maintained. For comparision, geany/src/* = 1.9 MB.
peas loader = ~15 KB, language support is in the core, and doesn't change with the new Geany versions, so you don't have to worry about any language(s) becoming unsupported/unmaintained.
Don't be ridiculous. This calculation is severely flawed and you know that.
I don't know anything like that. 150 KB per proxy is the best estimate we have at the moment.
To make an omelette, you have to break the eggs.
No, you don't. This can be implemented without breakage (at least for C plugins, probably for existing python ones too).
Since you have the enthusiasm to write additional language support, not me, and you are not willing to accept any suggestions, this discussion is pointless.