If it has a refcount, why not make it a GObject so that it's easy to create from non-C plugins (python via peasy for example).

If it has a refcount, why not make it a GObject so that it's easy to create from non-C plugins (python via peasy for example).

I just copied what was in TMTag to implement it quickly but good point, it could be a GObject. I'm not so familiar with what might be necessary for non-C plugins but how does #3849 look from this perspective? Could anything be improved there?

Would need to check in detail. Have you looked the gtkdoc that's generated from the new interfaces?

Have you looked the gtkdoc that's generated from the new interfaces?

What should I look for exactly? My main worry is

typedef struct
{
	gboolean (*autocomplete_provided)(GeanyDocument *doc, gpointer data);
	void (*autocomplete_perform)(GeanyDocument *doc, gboolean force, gpointer data);
	gboolean (*calltips_provided)(GeanyDocument *doc, gpointer data);
	void (*calltips_show)(GeanyDocument *doc, gboolean force, gpointer data);
	gboolean (*goto_provided)(GeanyDocument *doc, gpointer data);
	gboolean (*goto_perform)(GeanyDocument *doc, gint pos, gboolean definition, gpointer data);
	gboolean (*symbol_highlight_provided)(GeanyDocument *doc, gpointer data);
} PluginExtension;

which in C you would use this way:

static gboolean autocomplete_provided(GeanyDocument *doc, gpointer user_data)
{
}

static void autocomplete_perform(GeanyDocument *doc, gboolean force, gpointer user_data)
{
}

static PluginExtension extension = {
	.autocomplete_provided = autocomplete_provided,
	.autocomplete_perform = autocomplete_perform
};

void plugin_init(G_GNUC_UNUSED GeanyData * data)
{
	plugin_extension_register(&extension, 100, NULL);
}

PluginExtension can also be allocated dynamically which would probably be necessary for other languages. Is such an interface OK for other languages?

Generally speaking, non-C is supported well only for GObject-based interfaces. A python plugin can easily define a GObject-derived type purely implemented in Python.

For anything else you need at least some supporting C code around. This is essentially what the "lib"-part of peasy does. It defines GObject-derived wrappers around existing Geany interfaces so that plugins make instances and inherit properly. Not all Geany interfaces need wrappers. We declare some of them as "GBoxed" such that the gobject-introspection magic makes them available to non-C languages automatically. We feed the gobject-introspection machinery mostly by converting the doxygen output to gtkdoc, and then have it generate the typelib from that.

So for PluiginExtension we would need to extend peasy for sure.

I asked specifically for GeanySymbol. At the very least it needs to be a GBoxed, but if it has a refcount and getters/setters for anything anyway it could also be a real GObject. Then peasy wouldn't need to wrap this type much.

(no time for this right now, but…)
GObjects are nice for language inteop with GI indeed, but they aren't as cheap as e.g. a boxed type (just think about all the bells and whistles like properties, signals, private data, etc) and AFAIK a boxed type that has its own refcount works fine (just lies in copy() which actually just refs, and free() which just unrefs), and it's what we have for TMTag currently IIRC. I don't expect much custom code to support a proper GBoxed in Peasy, am I mistaken?

And for PluginExtensions I guess the worse part is how to annotate the data, I'm not sure which scope to give it. And yeah it might need some custom code there (or adjust the API if there's a better way that is reasonably easy and we agree on… :D).

GBoxed works for non-C. You just have to add a non-C-friendly allocation/constructor because there's no generic g_boxed_new().

GObjects are nice for language inteop with GI indeed, but they aren't as cheap

That's a good point, it should be cheap because for the symbol tree code, all the TMTags have to be wrapped by GeanySymbol first and it would be best to have the overhead as small as possible. If we wanted, we could change GeanySymbol to something like

typedef struct GeanySymbol
{
	ExternalSymbol *ext;
	TMTag *tag;

	gint refcount;
} GeanySymbol;

where ExternalSymbol would contain all the other members so GeanySymbol with the TMTag "backend" would be smaller and would not have to zero-fill so many members.

GBoxed works for non-C. You just have to add a non-C-friendly allocation/constructor because there's no generic g_boxed_new().

For GeanySymbol, this is hidden behind the two constructors:

GeanySymbol *geany_symbol_new_from_tag(TMTag *tag);
GeanySymbol *geany_symbol_new(gchar *name, gchar *detail, gchar *scope, gchar *file,
	TMParserType lang, glong kind, gulong line, gulong pos, guint icon);

so I believe it should be satisfied already.