Makes some sense, although it would be technically possible to simply set `subplugin->priv->proxy_data = module` in `plugin_load_gmodule()` before calling `geany_load_module()`.

If we go the additional arg way like this (which seem mostly OK to me, see below), we need to document `plugin_module_make_resident()` doesn't work with new-style API in `load()`, and probably deprecate it. Advertizing both functions depending on the call site seems overly odd to me.

However, most plugins probably only need to make the module resident after `init()` -- as `load()` will often not create `GType`s; and if a lot of plugins end up being resident when loaded (and all installed plugins gets "loaded"), it might have a largish and unwanted memory impact.

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

Yes, it would be better to do it in `init()` for best efficiency but IMO we should allow for doing it in `geany_load_module()` too, might be necessary and/or more convenient for some plugins.

Yes, i.e. for your examples using instance methods on a (GObject) class for init/cleanup etc.

The thing is, if we remove `plugin_module_make_resident()`, it becomes very hard for a plugin to call `g_module_make_resident()` from `init()`, as it would have to save the module pointer. This is not trivial without using a global variable, as plugins can only `set_data()` once, so this can't be used if the plugin wants to delay data allocation in `init()` (which most plugins should do). …and I feel odd about advertizing a different function to do the very same thing just depending on whether it's called from `load_module()` or not… other opinions? @codebrainz @elextr

FTR, as @codebrainz already mentioned somewhere, note that GModule has [`g_module_check_init()`](https://developer.gnome.org/glib/unstable/glib-Dynamic-Loading-of-Modules.ht...) hook, so a plugin can already call `g_module_make_resident()` before `geany_load_module()`, even if it might look less integrated.

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

We need a decision before 1.26 on this, and either merge something like this, or maybe advertize using `g_module_check_init()` for this purpose? @codebrainz @elextr (and @eht16 @frlan @ntrel) I'd really like your opinion on this as it affects public plugin API.

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

I like the idea of hiding it from plugins entirely, if it's feasible, as seems to be indicated above. My second favourite is to let plugins deal with this themselves by using `g_module_make_resident()` from within `g_module_check_init()`, or using dynamic type registration or whatever.

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

I would just deprecate it and recommend g_module_check_init() universally

But then it's tricky to only make the module resident in `init()`. Well, tricky meaning storing the module pointer and using it later, like if it was a `geany_load_module()` parameter.

```c static GModule *module_self = NULL;

G_MODULE_EXPORT const gchar* g_module_check_init(GModule *module) { module_self = module; return NULL; }

static gboolean myplugin_init(GeanyPlugin *plugin, gpointer data) { g_module_make_resident(module_self);

return TRUE; }

G_MODULE_EXPORT void geany_load_moule(GeanyPlugin *plugin) { /* ... */ plugin->funcs->init = myplugin_init; /* ... */ GEANY_PLUGIN_REGISTER(plugin, 234); }

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

Closed #719 via #760.

--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/719#event-464756408