HLS statically advertises support for functionality that is disabled by config

haskell / haskell-language-server

Official haskell ide support via language server (LSP). Successor of ghcide & haskell-ide-engine.

Apache License 2.0

2.61k stars 352 forks source link

HLS statically advertises support for functionality that is disabled by config #4084

Open michaelpj opened 4 months ago

michaelpj commented 4 months ago

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 (https://github.com/haskell/haskell-language-server/issues/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.

michaelpj commented 1 month ago

Wow, this is quite annoying and makes the logs pretty noisy. Perhaps I need to look into it more...

michaelpj commented 1 month ago

Brainstorming:

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!

michaelpj commented 1 month ago

Okay, so I think the first step would be to support dynamic registration better in lsp, see https://github.com/haskell/lsp/issues/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).