Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
@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);
(just a few quick replies, I'll go deeper later)
My point is that currently there is no way for a extension to know whether it "won" or not, so it can't know whether it should do ancillary actions (e.g. things in editor-notify, see e.g. my diff) related to the feature or not (assuming not everything does in _perform()).
What I am trying to suggest is that there should be a means for the extension to know that, instead of having a setting the user need to know about and tweak (also knowing which plugin effectively "won").
Maybe it's fine and the no two extension can return TRUE for the same provided() call, but it seems a bit brittle and hard to get to work long-term.
A "simple" (but not very elegant I'd say) solution could be always calling _provided() at least once per document, and the extensions must track whether they got called for a document (and so it didn't got "caught" by another extension) before doing anything else.
Basically my point is that if we wanted to have the Geany features use the extension mechanism, how would it know whether it's active or not? It's a fallback for all calls (basically returning TRUE for all the _provided() calls), and so the question is "was it overridden"?
This sort of support could be useful for other things if we expand it further, e.g. a fairly generic indenter based on a fairly generic algorithm, and a specialized one (e.g. clang-format) that both handle some of the same documents, but with different levels of "quality". Currently I don't see a solution for those 2 to work together, unless each has an option to select what it supports or not, and it's properly configured (which could be a nightmare).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.