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
For example: if the semantic tokens plugin is disabled, we still see we have a plugin that provides handlers for the semantic tokens methods and so say we support it (#4081).
Probably the "correct" thing to do would be to not statically advertise support and instead dynamically register for it when the plugin is turned on. Similarly we ought to unregister if the plugin is turned off...
This would be pretty complicated to arrange, however, and is quite different from what we do today.
The text was updated successfully, but these errors were encountered:
We probably need plugins to offer both "static handlers" and "dynamic handlers"
A "dynamic handler" is going to need to provide both a handler and some contribution to the registration options
We probably need a semigroup instance for the various registration options to "sum up" what we offer
When we get a config update, we might need to change what is registered. The simplest thing to do would be to unregister everything and re-register it. That also means we can "re-create" our registration options from scratch, which might be the simplest thing to do.
This is going to need a whole bunch of machinery for tracking what we have dynamically registered and un-registering/re-registering it as appropriate.
Really, anything which can be disabled by config needs to be a dynamic handler!
Okay, so I think the first step would be to support dynamic registration better in lsp, see haskell/lsp#583
That would give us basically all the pieces to do our usual "multiple handlers for one method" thing while also providing capabilities, since we would already have a way to union up the capabilities.
Then we need the aforementioned mechanics for keeping track of what is dynamically registered and what should be, plus ideally a nice way of defining our handlers so they can be either static or dynamic depending on what the client supports (perhaps also something we can make easier in lsp).
For example: if the semantic tokens plugin is disabled, we still see we have a plugin that provides handlers for the semantic tokens methods and so say we support it (#4081).
Probably the "correct" thing to do would be to not statically advertise support and instead dynamically register for it when the plugin is turned on. Similarly we ought to unregister if the plugin is turned off...
This would be pretty complicated to arrange, however, and is quite different from what we do today.
The text was updated successfully, but these errors were encountered: