@b4n commented on this pull request.

In src/pluginextension.c:

> + * the list and executes the @c _perform() function of the first extension in
+ * the list whose @c _provided() function returns @c TRUE.
+ * 
+ * This function is typically called in the plugin @c init() function.
+ * 
+ * Plugins wishing to re-register themselves, e.g. with a different priority,
+ * should first unregister themselves using @c plugin_extension_unregister()
+ * and call @c plugin_extension_register() afterwards.
+ * 
+ * @param extension The @c PluginExtension structure instance provided by the
+ * plugin.
+ * @param ext_name Human-readable name of the extension that can appear in
+ * the user interface. The string should be reasonably unique so extensions can
+ * be distinguished from each other.
+ * @param priority The higher number, the earlier in the extension list the
+ * plugin is and the higher chance it becomes called when multiple extensions

We probably don't want to be too specific here, at least not for now.

Also, I feel like the wording here is a little too much of an incentive for extension authors to just put a ridiculously high value -- because their extension is awesome, right?
I'd like to have some rough guidelines on values here as mentioned earlier somewhere. I'd suggest something like this (actual numbers are pretty arbitrary though):

• if the extension is the only thing the plugin provides, and if it targets a single filetype, use 400 <= priority < 500.
• if the extension is the only thing the plugin provides, but it targets several filetypes, use 300 <= priority < 400.
• if the plugin provides other features than the extension, but it only targets a single filetype, use 200 <= priority < 300.
• if the plugin provides other features than the extension, and targets several filetypes, use 100 <= priority < 200.
• a priority of 0 or less is reserved, and using it has unspecified behavior.

My idea being that the more specific the plugin is, the less likely the user enabled it without actually wanting the extension feature, while if it's one of the many things the plugin does, disabling the plugin might not be a good option to let another plugin handle one of the extension calls.

This might even be a good reason for a plugin to register separate extensions, so if one of the calls is very specific but some other very generic it can use different priorities for each.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <geany/geany/pull/3849/review/2135465153@github.com>