@b4n commented on this pull request.
> + void (*calltips_show)(GeanyDocument *doc, gboolean force);
+
+ gboolean (*goto_provided)(GeanyDocument *doc);
+ void (*goto_perform)(GeanyDocument *doc, gint pos, gboolean definition);
+
+ gboolean (*doc_symbols_provided)(GeanyDocument *doc);
+ GPtrArray *(*doc_symbols_get)(GeanyDocument *doc);
+
+ gboolean (*symbol_highlight_provided)(GeanyDocument *doc);
+
+ gchar _dummy[1024];
+} PluginExtension;
+
+
+void plugin_extension_register(PluginExtension *extension);
+void plugin_extension_unregister(PluginExtension *extension);
> OK, what about modifying every `_provided(GeanyDocument *doc)` to […]
Yeah that's a good idea, and I came to it as well partly separately, so it
might be a good, or at least obvious, answer :)
> Where would this `user_data` get passed? When you call `_perform(...,
> user_data)`, the plugin won't know what to do with the data as it comes from
> Geany and it doesn't have any callback where it would pass it. The
> `_provided()` functions are synchronous and also don't know what to do with
> such data.
I guess we didn't understand each other here. My point is that at
`_register()` time the extension gives some data, and when calling the vfuncs
it gets passed in, allowing to remove all global state in the extension's
implementation.
E.g. for a C++ wrapper it could do (pardon my rusty C++):
```c++
void foobar_provided(GeanyDocument *doc, gpointer data)
{
static_cast<Foo*>(data)->foobar_provided_impl(doc);
}
Foo::Foo()
{
plugin_extension_register(vtable, this);
}
```
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3849#discussion_r1628391090
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3849/review/[email protected]>
