You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your enhancement request related to a problem? Please describe.
To solve #3636, I had to split the hls-pragmas-plugin into three separate plugins (see #3640),
so that I could decrease the priority of the "disable this warning" codeAction.
A cleaner solution would be to have a single plugin with priorities set for the individual PluginHandlers.
Describe the solution you'd like
A property for each pluginHandler (analogous to the PluginDescriptor.pluginPriority property) that lets us define the priority of each pluginHandler.
This priority should be used to sort the code actions and completions.
The text was updated successfully, but these errors were encountered:
Or we could go even further, and return some type from a plugin handler other than the bare LSP response type, and then we could put the priorities into the result type for things that look like "a list of results".
Unclear whether this would necessarily be an improvement. At the moment the plugin is our "unit of configurability", and maybe we should just live with that as a coherent design.
Is your enhancement request related to a problem? Please describe.
To solve #3636, I had to split the
hls-pragmas-plugin
into three separate plugins (see #3640),so that I could decrease the priority of the "disable this warning" codeAction.
A cleaner solution would be to have a single plugin with priorities set for the individual
PluginHandlers
.Describe the solution you'd like
pluginHandler
(analogous to thePluginDescriptor.pluginPriority
property) that lets us define the priority of eachpluginHandler
.The text was updated successfully, but these errors were encountered: