What's the correct way for an LSP server to know whether a command is available on the client?

[DanTup]

I'm implementing some refactors where the server needs some input from the user. In order to get input from the user I'm going to need to trigger a command on the client that can ask the user for input (for example, by having a command in the client extension that can call window.showInputBox or some equiv).

However, I can't find a way for the client to advertise (or server to know) which commands are supported on the client.

What's the expected way to handle this? Although I can document the commands that a client needs to implement for specific functionality in the server, that's not very compatible - if I wanted to add new requirements in the future, I'd need to know if the connected client supports them.

[dbaeumer]

Asking for input is not supported in the LSP right now and using commands for this is IMO the wrong way to approach this.

If we thing a server should be able to ask for user input we should add corresponding requests send from the client to the server.

However in general I am more a fan of having more refactoring requests that flow from the client to the server and the client queries the input parameters upfront.

[mickaelistria]

+1, the LSP should work on identifying and spec'ing usual refactoring contracts instead of introducing some too generic and not sustainable framework to orchestrate interaction with users. The risk is that is we start allowing user interaction, we'll basically redefine a form toolkit like many have existed and failed; we can do better and reach better quality and sustainability by bringing the knowledge inside the LSP spec. Do you think you could spec the refactoring you're working on as LSP operations?

[DanTup]

However in general I am more a fan of having more refactoring requests that flow from the client to the server and the client queries the input parameters upfront.

I don't think this changes the problem. The server needs to know whether it can provide a code action that relies on getting user input, and that means the server needs to know if the command that it'll assign to the code action is available.

For example, in v1 of my LSP server, I have 0 code actions. In v2, I add a code action for "Extract Widget" which requires some input from the user. Even if I implement that user input in the client extension (which I think increases the burden on the client extension dev, but that aside..) I need to know whether the connected client has the implementation for this, and therefore I need to know if I can send the code action that references that command?

(So I think the rename of this issue may be misleading - I think it's valuable for a server to know whether a client extension implements/supports a command, whether it's for asking for input or not?).

[DanTup]

Do you think you could spec the refactoring you're working on as LSP
operations?

In this case, the one I'm trying to implement is "Extract Widget". It's basically similar to behaviour of Extract Method, however it needs to exist alongside it (because it creates a special class, not just a method, and creating a method is also valid). This is very specific to Flutter so I don't think it's likely the LSP spec would ever have a specific request for it.

Of course, we can implement a lot of this by just adding more code to the client, but then we lose some of the benefit of LSP (making it simple to get the language into other editors).

I understand the concerns with exposing things like input to the server (since it could lead to a crappy experience if I request 5 pieces of input individually in an editor like VS where the user would expect a dialog with them all) but without this, I think there would need to be some fairly flexible API that allows for custom refactors that are fairly specific to a server.

[DanTup]

However in general I am more a fan of having more refactoring requests that flow from the client to the server and the client queries the input parameters upfront.

Sorry, I think I misunderstood this as something that we should do ourselves, but I guess you mean extending LSP to be able to query the server for this metadata and then let the client (editor, not extension) handle collecting the input?

[mickaelistria]

Of course, we can implement a lot of this by just adding more code to the client, but then we lose some of the benefit of LSP (making it simple to get the language into other editors).

Indeed, protocol extensions loose most benefits of using LSP.
But many SDK make it relatively easy to add protocol extensions, so while the operation wouldn't be portable out of the box, it would still be "cheap" to implement in some IDEs of choice.

In this case, the one I'm trying to implement is "Extract Widget". It's basically similar to behaviour of Extract Method,

Can't you instead of requesting user input upfront, deal with parameter capturing in a similar way as a CompletionItem, allowing Snippet mode which allows to modify parameters after the refactoring?
Note that I'm not sure how this fits in current protocol, but I think I've already reported in some other issues that parameter capturing (after edit) could be useful in WorkspaceEdit as well so they could be used in almost all operations; so you use-case could help improving that.

[mickaelistria]

Danny Tuppeny (@DanTup) : basically, could #592 be the solution here?

[DanTup]

Can't you instead of requesting user input upfront, deal with parameter capturing in a similar way as a CompletionItem, allowing Snippet mode which allows to modify parameters after the refactoring?

In this specific case (Extract Widget) it probably would, but it'd require workspace/applyEdit to support snippets. I don't think it'd help if the options weren't directly tied to symbols in the code though (for ex. if there were non-string options for a refactor) or if it spanned multiple files (I presume we can't do snippet mode across multiple files?).

That said - I still think the original request is very valid. A client should be able to communicate which commands it supports to the server. Servers can return identifiers of commands against code actions - why shouldn't they be able to know whether or not the client can actually handle it?

If I want a code action that requires a lot of custom code running in the client extension, I'd want to do something like:

• Server sends code action with a client command identifier
• Use selects the code action, which invokes the local command in the extension
• Extension does stuff, collects user input, whatever
• Extension then calls executeCommand with the data for the server to process the action

The first step here should be able to read a capability from the client to know what the client command is available. I'm not saying the client should transmit all its internal commands, it's fine for the client extension to have to declare them (like the server declares which it can handle, so the client knows when to send them on to it).

[dbaeumer]

A server at the end should only trigger those commands it implements or has documented as something the client extension needs to provide.

I think it will not be enough if a client lists these commands. It would require specing their behavior as well. This is why I think we are better off specing a corresponding request or notification.

[DanTup]

A server at the end should only trigger those commands it implements or has documented as something the client extension needs to provide.

But then how do I add a new code action that requires a command from the client extension that wasn't in the first shipping version? Isn't the purpose of client capabilities to communicate this sort of thing? The server already advertises which commands it supports, so it seems natural (to me) for the client to do the same - they they both know which commands are available on the other.

[dbaeumer]

The reason why a server advertises its commands is that a client knows about them and delegates the execution of the commands back to the client. If is more like a function dispatching.

As said I am not a fan of starting to spec client commands for the above reasons. Even if clients advertise them we would need to specify what they are support to do. Or am I misunderstanding you?

[alanz]

I think requiring a client to be code specifically for a given feature in a server is a bad idea, and goes against the whole point of LSP.

For the haskell refactorer I eventually realized you can go a long way using just code actions and rename, if you apply default names to say a newly extracted widget.