Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
michaelpj opened this issue Feb 18, 2024 · 3 comments
Labels
type: bug Something isn't right: doesn't work as intended, documentation is missing/outdated, etc..

Comments

@michaelpj
Copy link
Collaborator

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.

@michaelpj michaelpj added type: bug Something isn't right: doesn't work as intended, documentation is missing/outdated, etc.. status: needs triage and removed status: needs triage labels Feb 18, 2024
@michaelpj
Copy link
Collaborator Author

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

@michaelpj
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug Something isn't right: doesn't work as intended, documentation is missing/outdated, etc..
Projects
None yet
Development

No branches or pull requests

1 participant