Open daviwil opened 6 years ago
I'm missing something, could you please clarify why we're required to use any of these?
If I understand correctly, according to the spec, the sending is done the same way - we pass a method name, and an args/params object. So in our case, we're just passing an RegistrationParams
object which has an array of Registration
objects?
Actually, it seems the RegistrationOptions for the given Request/Notification types aren't even being used in those overloads, they're just a facet of the Request/NotificationType signature. My statement about changing the overloads was incorrect. The largest part of the work will be in dealing with the client/registerCapability
request to dynamically wire up language features.
The real reason we would need to change overloads is to make use of the CancellationToken parameter which has nothing to do with dynamic capability registration. Maybe in the future we can make a PR to the vscode-jsonrpc project to add overloads that take a CancellationToken without the need for a Request/NotificationType parameter.
By the way, I love your avatar, that movie is awesome ;)
So, for now we're only going to cancel requests via a $/cancelRequest
request until we make a PR to vscode-jsonrpc or if Request/Notification types start receiving a CancellationToken
object? I like it.
I understand it's a part of vscode anyway, so why hasn't it been an existing overload on vscode-languageserver-node
this whole time? :confused:
By the way, I love your avatar, that movie is awesome ;)
;)
Probably wasn't added as an overload to the "simple" sendRequest/sendNotification methods because vscode-languageclient switched over to the new method of specifying request and notification types before adding request cancellation. I doubt there's a limitation that prevents it from being added, so I'll try to add it and send a PR to them.
Turns out vscode-jsonrpc does support a CancellationToken parameter in the "overload" of sendRequest which accepts a simple method name and parameter list:
https://github.com/Microsoft/vscode-languageserver-node/blob/master/jsonrpc/src/main.ts#L928
They just look at the last item in the list of params and check if it's a CancellationToken. I'll add this information to issue #140 as well.
Development of atom-languageclient has officially moved to https://github.com/atom-ide-community/atom-languageclient 🎉
If this is still an issue please consider opening an issue on that repo.
Language Server Protocol v3 introduces dynamic registration of capabilities, allowing the server to register support of a particular capability with the client, also passing options to configure the client's use of that capability.
This will require us to use a different set of method overloads in vscode-jsonrpc's client library for sending requests and events:
https://github.com/Microsoft/vscode-languageserver-node/blob/master/jsonrpc/src/main.ts#L269