The separate API allows to do the registration in the plugin's init(), and have the file extensions deppend on plugin configuration. Also a API-wise separattion to geany_plugin_register() is needed to allow for nested proxies.

I get that, my point was that I would find the API less odd if one filled a specific structure, rather than one already used for something else.

e.g. ```C Proxy proxy = { .extensions = { "so", NULL }, .load = my_load, .probe = my_probe, .unload = my_unload }; geany_plugin_register_proxy(plugin, &proxy); ``` or alike. But I know it has drawbacks, like binary incompatibility if the struct expands (solvable by versioning the struct, but a bit annoying), etc.

I don't really mind though, as it does has a few advantages (at least being simple and easy to expand), and that API won't be used by everyone so any oddness won't affect too many people.

A proxy can be a proxy for many types. the only limitation is that only one set of ProxyFuncs is supported per proxy. But this limitation is not a problem, since the proxies can do their own dispatching. For geany it simplifies storing the pointers (avoids introducing a list of vtables, etc)

Okay, so maybe that part is not really relevant indeed.

--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/629#issuecomment-143058333