<div dir="ltr"><div><div>Martin i just pushed the code, only tested using geanypy in my repo which should be the latest, i think it pulls from git automatically and repackages it for me.<br><br></div>i normally checkout the projects and symlink them into the geanypy folder, if you get stuck ping me on irc g+ or email with the error and I will do my best to help.<br>
<br></div>also you need to add some project folders in the prefs, any sub folders to that path are considered a project and will create a geany.history file within the project and geany.project file.<br><div><br></div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 18, 2014 at 9:50 AM, Lex Trotman <span dir="ltr"><<a href="mailto:elextr@gmail.com" target="_blank">elextr@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[...]<br>
<div class="">><br>
><br>
><br>
> The root problem is that geanypy is a plugin at all!<br>
<br>
</div>In the sense that being a plugin causes the restrictions you list below, yes.<br>
<br>
But its only because the plugin interface does not contemplate the<br>
situation of one plugin being a "proxy" for several others.<br>
<br>
Matthew did a great job making Geanypy within the restrictions of the<br>
existing API.<br>
<div class=""><br>
><br>
> The support for non-C plugins should be in the core as well, then Python<br>
> (and others languages) plugins can be first-class-citizens in all aspects<br>
> that are problematic right now:<br>
>  * Distribution within geany-plugins<br>
>  * Adding Keybinding to geany<br>
>  * Listing plugins<br>
><br>
> Really, if the core is hesitant to large changes, then it should at least do<br>
> as best as possible to support plugins which implement these changes. It's<br>
> the core's job to provide the best experience for plugin developers.<br>
<br>
</div>It would be better that the API be modified like this, so that<br>
something like Geanypy could act as a proxy for other plugins (which<br>
appear as "first class" plugins) and so a plugin can provide bindings<br>
of the API in another language.<br>
<br>
This allows more languages to be added easily by anyone rather than<br>
requiring changes to core for each language someone wants to use for<br>
plugins.  (this might even solve the VAPI argument, just make it a<br>
plugin, or more than one plugin if no agreement is reached :)<br>
<br>
Cheers<br>
<span class="HOEnZb"><font color="#888888">Lex<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> Best regards<br>
><br>
> _______________________________________________<br>
> Devel mailing list<br>
> <a href="mailto:Devel@lists.geany.org">Devel@lists.geany.org</a><br>
> <a href="https://lists.geany.org/cgi-bin/mailman/listinfo/devel" target="_blank">https://lists.geany.org/cgi-bin/mailman/listinfo/devel</a><br>
_______________________________________________<br>
Devel mailing list<br>
<a href="mailto:Devel@lists.geany.org">Devel@lists.geany.org</a><br>
<a href="https://lists.geany.org/cgi-bin/mailman/listinfo/devel" target="_blank">https://lists.geany.org/cgi-bin/mailman/listinfo/devel</a><br>
</div></div></blockquote></div><br></div>