Am 19.05.2014 13:13, schrieb Lex Trotman:
On 19 May 2014 19:58, Matthew Brush mbrush@codebrainz.ca wrote:
On 14-05-18 10:10 PM, Lex Trotman wrote:
[snip]
- the effort to incorporate it into the existing PM.
I don't think this will be very difficult, even from me who loathes GtkTreeView :)
IIUC Thomas' proposal would use the existing methods so it doesn't require any changes in these areas.
But it requires writing own libpeas (ie. scanners,
Unless I have misunderstood Thomas (have I?) he is using the existing scanner.
Yes, you got this right. And I have already done it locally with +260/-160 LOCs.
loaders+runtimes,
again existing
Only geanypy, not javascript. And it'll require some more work to adapt to the new core infrastructure.
+gobject-introspection-bindings, etc).
As said in my previous post, bindings have nothing to do with the loader.
That's right. The bindings question is orthogonal to the loader-infrastructure one. But I think Matthew is working on autogenerating bindings which is great (I'll try to help where I can). Then we can focus on the loader question more easily.
The main difference between the two options is that libpeas can provide loaders for new languages simply (as shown by Matthew loading Python3) but at the cost of having to integrate something very different to the current system, whereas Thomas' proposal is a simple extension of the existing system to fix Geanypy problems but doesn't offer loading of any extra languages without further effort.
Another key difference is that in my proposal the loaders are also normal plugins (I call them pluxys) that use the same infrastructure (and therefore appear in the PM dialog). The pluxys can therefore offer more that just proxying (though I would not recommend it) and can easily be maintained by a third party. With libpeas, they come with libpeas and are separately enabled/disabled (though we could probably work the peas loaders into the PM gui somehow). On the other hand, it might be preferable to separately manage pluxys.
Yet another key difference is the .ini file approach used by libpeas vs. fixed symbols in the .so files used by Geany. I too think the .ini approach is superior but unfortunately it's a break for existing plugins.
To my mind both approaches have their good points, and both have their downsides.
As I said before, I am not able to pick a best solution at this point.
To my mind the important question is "how hard is it to change Geany to allow libpeas loaded plugins to register keybindings?" with the secondary question of the PM as well (its more the interface from peas to the PM code than the treeview, since it has to work with existing plugins as well). If those potential problems are solved then libpeas may provide a faster path to more languages, though only C (so C++ & Vala I guess), Python, javascript and something called seed are currently available. I would really like to know what plans there are for others?
seed == javascript, IIUC
I don't know what the plans are but libpeas doesn't appear to be actively developed. The last mailing list activity is from may 2012. It was a question by an ubuntu developer, and it remained unanswered. The git log is only slightly more promising.
So I absolutely do not expect that libpeas will add new languages in the short-mid term (or change at all), so (from our POV) it only adds javascript to the pool. Adding more language, which I would love to see, will require effort from our plugin authors. And I expect we would need to clone/fork libpeas (similar to scintalla) because the APIs to add language loaders are not public and presumably unstable (but again, I don't expect libpeas to change at all due to inactivity).
Sorry if I sound negative towards libpeas. I'm not fundamentally against it. I try to objectively evaluate it, and it doesn't appear to be the holy grail either, especially with our strong focus on maintaining the plugin ABI/API and exposing the current API via bindings.
Best regards.