Skip to content

LSP Server will not expose any capabilities if the client does not inform the server of it's capabilities #149

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

Closed
david-driscoll opened this issue Jul 13, 2019 · 0 comments
Labels
enhancement New feature or request question Further information is requested

Comments

@david-driscoll
Copy link
Member

This is an issue that has popped up time and time again where sometimes a client doesn't bind properly because the capabilities returned in the wrong shape. This has been because I was following the spec a little to strictly along the V3 line, and ignoring some of the v2 behaviors (Sorry!)

I'm making a fix now that will correct the issue and we'll have the following behaviors.

  1. If the client supports dynamic registration for a capability
  • We will follow that strictly. If dynamic registration is true we will not report any static capabilities. This is intended because if we do then we run into issues with binding to the same handlers on the client side twice (once at initialization and once again that dynamic registration).
  1. If the client does not support dynamic registration, and explicity sets dynamicRegistration to false
  • We will return the expected static capability
  1. If the client does not report any capabilities, or support for a particular capability through the capabilities object, we will report our capabilities statically, assuming that if the client supports them it will bind to them. This is the new behavior

PR: #148

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant