-
Notifications
You must be signed in to change notification settings - Fork 184
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
Start with basic dynamic capabilities #911
Conversation
What server needs dynamic registration on such a fundamental feature? |
plugin/core/sessions.py
Outdated
@@ -125,6 +129,7 @@ def __init__(self, | |||
self._on_post_initialize = on_post_initialize | |||
self._on_post_exit = on_post_exit | |||
self.capabilities = dict() # type: Dict[str, Any] | |||
self.dynamic_capabilities = BidirectionalDictionary() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since I'm pretty new to the code, I was confused that capabilites
actually means server_capabilities
. Maybe worth renaming? And then also the same for dynamic_capabilities
probably.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And it would be ideal if both are merged into one dict (or a custom form of dict). :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And it would be ideal if both are merged into one dict (or a custom form of dict). :)
I agree, this pull request needs more work.
And according to the specification, servers shouldn't do that:
|
While eslint uses But in any case, do we really need to have specific examples of servers that use it? Isn't being spec-compliant and supporting more features generally a good thing? I think it will only save us work in the future if we do it now. |
OmniSharp wanted dynamic capabilities for text synchronization #661 I don't know whether OmniSharp advertises them as static capabilities in the meantime (they should, of course :)) ESLint registers workspace/didChangeConfiguration and workspace/didChangeWorkspaceFolders. rls registers textDocument/rangeFormatting #372 (but only after the user sets up suitable settings!). I don't know whether this is still the case for the rust language server. vscode-json-language-server also registers textDocument/rangeFormatting. I haven't included textDocument/rangeFormatting for now.
I don't like writing speculative code as that's a waste of time, but in this case I consider the LSP spec as a baseline we should implement. |
To clarify the Omnisharp case - they supported both static and dynamic configuration, but broke their static configuration logic. LSP doesn't exist to work around their bugs. Range formatting was the common use case for dynamic capabilities, I think it would be better to start with that capability as its logic is not so deeply plumbed into LSP itself. |
Oof, this looks to be more random than I initially thought. So I have this idea of mapping the received methods to toggle server capabilities on/off. Perhaps there's a better strategy that I'm not seeing yet.
|
Yes, it would break servers. https://github.com/vscode-langservers/vscode-json-languageserver, for example, doesn't register For reference, here is a log of Request
Response
|
d7ecd80
to
a0a2961
Compare
OK well being a bit more lax about correct handling of client/registerCapability I see this stuff for the jedi language server:
|
"workspace", {}).setdefault( | ||
"workspaceFolders", {})["changeNotifications"] = registration["id"] | ||
else: | ||
printf("WARNING: unknown registration method '{}' from {}".format(method, self.config.name)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Better to format like that than using second argument of printf
?
Spec says |
Well, I think for now it's OK to mutate the Also, here are the interesting payloads from jedi condensed:
|
Does that refer to my comment? |
I replied to this:
I thought you meant that we should keep two dicts: one with static capabilities and one with registered capabilities. |
I mean that we (the client) should advertise support for |
I've said that before. Let me check if that's really a problem now. |
But does vscode-json-languageserver really need workspace change notifications? |
Anyway the story is not done, I'll work on this more but it's something at least. |
Never mind. I was confused as this change is about |
We can always expand/change this in the future.
For now, we understand dynamic registrations of the following methods:
textDocument/didOpenWe notify the server if the server registers this method.
textDocument/willSaveWe notify the server if the server registers this method.
textDocument/willSaveWaitUntilWe do the request if the server registers this method.
textDocument/didSaveWe notify the server if the server registers this method.
textDocument/didCloseWe notify the server if the server registers this method.
workspace/didChangeConfigurationRegistering this capability does nothing interesting: we only notify
a change in configuration when we initialize the session.
(this is a problem of ST3, but we can improve this in ST4)
workspace/didChangeWorkspaceFolders
Does something interesting: if the server doesn't support workspaces,
but does register this capability, we'll notify of changes in the
workspace.
Of course, if the server already advertised (static) capabilities fore.g. TextDocumentSync, then registering for textDocument/didOpen does
nothing useful.
Let's focus on didChangeWorkspaceFolders for now.