@techee commented on this pull request.
- */
+#define CALL_PROVIDED(f, doc, ext) \ + G_STMT_START { \ + for (GList *node = all_extensions; node; node = node->next) \ + { \ + PluginExtensionEntry *entry = node->data; \ + \ + if (entry->extension->f && entry->extension->f(doc, entry->data)) \ + return (ext) ? entry->extension == (ext) : TRUE; \ + \ + if ((ext) && entry->extension == (ext)) \ + return FALSE; \ + } \ + return FALSE; \ + } G_STMT_END +
That's not the whole story - in addition to the static priority, there's also a dynamic aspect of all this.
Consider for instance `autocomplete_provided()` and `autocomplete_perform()` and the LSP plugin and let's say that for the queried document there's a LSP server configured. 1. Geany calls `autocomplete_provided()` of the LSP plugin - since the server isn't started yet, the plugin returns `FALSE` but launches the LSP server in parallel. 2. Until the server is started and the handshake with it completed, other registered extensions may perform the work even if they are behind in the chain. 3. Some time passes and `autocomplete_provided()` is called again by Geany. This time, the server is started. But even though it's started, it doesn't automatically mean it supports autocompletion - so depending on the server capabilities, the plugin returns either `TRUE` and starts performing autocompletion, or `FALSE` and keep others in the chain performing it. 4. If the server is re-configured or e.g. crashes or doesn't run for some other reason, others may perform autocompletion again. 5. And of course, if you disable autocompletion in the LSP config, it will always return `FALSE` without any attempt to start the LSP server.
Anyway, every `_provided()` function should be fast and return quickly without much processing. And I really don't expect thousands of plugins wanting to implement this interface.