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

Should ServerCapabilities depend upon ClientCapabilities? #503

Open
joyfulmantis opened this issue Jul 8, 2023 · 1 comment
Open

Should ServerCapabilities depend upon ClientCapabilities? #503

joyfulmantis opened this issue Jul 8, 2023 · 1 comment

Comments

@joyfulmantis
Copy link
Collaborator

Currently, inferCapabilities is passed a version of ClientCapabilities, and the passed client capabilities are used twice, once for RenameOptions and once for CodeActionKinds. That's a very small portion of the capabilities that could depend on ClientCapabilities. I'm of the position that ServerCapabilities shouldn't depend at all upon ClientCapabilities, after all, capabilities mean what we can do, not what we will do (which is to comply with the client capabilities in server code).

As long as no one objects I would like to stop passing ClientCapabilitise to inferCapabilities, and remove any code in there that refers to it.

@michaelpj
Copy link
Collaborator

Sadly, the spec says no...

RenameOptions may only be specified if the client states that it supports prepareSupport in its initial initialize request.

and

The server provides code actions. The CodeActionOptions return type is only valid if the client signals code action literal support via the property textDocument.codeAction.codeActionLiteralSupport.

Stupid, but that's what it says. It would be super helpful to document this, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants