[...]
The root problem is that geanypy is a plugin at all!
In the sense that being a plugin causes the restrictions you list below, yes.
But its only because the plugin interface does not contemplate the situation of one plugin being a "proxy" for several others.
Matthew did a great job making Geanypy within the restrictions of the existing API.
The support for non-C plugins should be in the core as well, then Python (and others languages) plugins can be first-class-citizens in all aspects that are problematic right now:
- Distribution within geany-plugins
- Adding Keybinding to geany
- Listing plugins
Really, if the core is hesitant to large changes, then it should at least do as best as possible to support plugins which implement these changes. It's the core's job to provide the best experience for plugin developers.
It would be better that the API be modified like this, so that something like Geanypy could act as a proxy for other plugins (which appear as "first class" plugins) and so a plugin can provide bindings of the API in another language.
This allows more languages to be added easily by anyone rather than requiring changes to core for each language someone wants to use for plugins. (this might even solve the VAPI argument, just make it a plugin, or more than one plugin if no agreement is reached :)
Cheers Lex
Best regards
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel