But IMHO it is not just a change for the sake of change but a change for consistency and cleanup.

I sympathize with the idea of using current APIs in general. However, as said we made quite some efforts to make sure the older API is still fully functional -- and if you check Geany's code, it's basically a compatibility module which does not add complexity to the actual loader :)
So yeah it's likely some new features could be exclusive to the the API, but it's unlikely we'd have to drop support for the old one. And while it could indeed be nice for cleaning up some of Geany's code, we like avoiding unnecessary burden on plugin developers -- the reason why we went to great length not to drop the old API at first. Remember that there are some plugins not on this repository.
So… I'm feeling kind of conservative here, but I'd prefer to see this kind of changes as part of a development effort on the plugin, suggesting interest and testing in that very plugin -- because yeah, it seems like a fairly innocent change without too much risk, but…

Also, there was some reason to design the new API or not?

Yes, mostly to make it easier/possible to write "proxy" plugins that can load other plugins (like https://github.com/kugel-/peasy).

Anyway, I should maybe have opened a discussion before starting this one. So I say sorry for my "bold" PR flood.

Well, don't get me wrong :) I like the initiative of proposing changes and writing the code. Yes, sometimes discussing it ahead can save a little time (mostly on the person actually writing the code), but so long as you can accept "no" (or "please change this that and that") as an answer it's all good.

And despite what I'm saying that I don't really like changing working code for something that isn't tremendously simpler or adding new features or fixing bugs, if @frlan or other want it to happen I'll be fine :)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.