Description
There is existing protocol for a client to request a server to execute a command. We have several places where we want to have the reverse. The server asks the client to execute command instead.
This would work in the same way as the client->server message: https://microsoft.github.io/language-server-protocol/specifications/specification-current/#workspace_executeCommand
We could use the same name workspace/executeCommand or use a different name to emphasize that the message flows in the opposite direction e.g. workspace/clientExecuteCommand.
This proposal may seem a bit strange, if we assume that all commands are defined by the server itself. However that is not typically the case in practice. In practice the server contributes commands and these commands get entered into some type of client-side command registry. There are actually more commands that exist client-side than just those defined by the server itself. (e.g. some commands may be defined by the client itself, or some commands may defined by other servers with which the current server interoperates somehow).
For this proposal to make sense, all we have to assume is that some commands 'exist' on the client that are not defined by the server itself. We do not need to assume a specific mechanism by which these commands are defined. So it should be possible to agree on a 'standard' mechanism to request the execution of a client-side command.
For some context...
We have run into several cases where we needed this and in each case it was handled by some custom protocol extension.
The latest of these is here: eclipse-wildwebdeveloper/wildwebdeveloper#543 (comment)
There has also been some discussion in other related LSP tickets, which I can sumarize again here:
#430 is probably the most closely related, one part of what it needs/asks for is a mechanism for server to request client to execute a command.
#432 has a discussion around whether commands live in a 'shared/global' name space or whether the commands belong only to a specific client<->server session.
With a shared namespace one server could define a command and another one could use it (e.g. in code action, or also in a potential executeClientCommand request. With 'per session namespace' this wouldn't be possible.
#642 is about defining a mechanism for a server to discover what commands a client actually supports.
These tickets digressed into long discussion which do not seem immediately actionable.
So I propose in this ticket to narrow the scope a bit, to make it more actionable.
Let's avoid getting into discussions about:
- how exactly commands may be defined on the client side (we just need to accept that they can be defined/exist somehow)
- whether client-side commands are in a global name space
- whether/how a server can discover which commands are supported on the client
Instead I intend this ticket to be only about adding a single protocol message that allows the server to request the client to execute a command.