Add an equivalent to VS Code's WorkspaceEditMetadata.isRefactoring

[DanTup]

VS Code has a new WorkspaceEditMetadata.isRefactoring field:

Provide metadata for workspace edits

The API to apply a workspace edit now lets extensions provide metadata, for example for marking the edit as being a refactoring. This extra metadata will be honored by the editor and Auto Save after refactoring (setting: files.refactoring.autoSave).

As far as I can tell LSP/the VS Code LSP client do not have anything to set this. It seems like a fairly VS-Code-specific thing to have, but presumably the expectation is that languages using LSP can still behave the same way as those that don't.

[puremourning]

isn't this what https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#codeActionKind is for?

[DanTup]

WorkspaceEdits can be sent from the server with workspace/applyEdit which the client may not know is a refactor or not (for example a refactor code action could just have a command because the edit is expensive and computed lazily when the user invokes the action).

(I assume this is the reason VS Code added it, and didn't just use the CodeActionKind, but I don't know - I just saw it in the release notes and figured it was something we should adopt in our LSP server to match).

[puremourning]

if client sends a command in response to a codeAction it knows that it was a refactor right?

I don't think that any sane client is going to apply a applyEdit unless it requested it via a command . that would be Cthulhu!

[DanTup]

if client sends a command in response to a codeAction it knows that it was a refactor right?

It knows the command execution is, yes. But it cannot assume that if it gets a workspace/applyEdit two seconds later, that it was a result of that command execution, surely? The communication is all asynchronous and workspace/applyEdit does not have a trail back to the action sent to the server that triggered it (at least as far as I know).

(so as far as I know, a client couldn't only apply edits tied to commands as you suggest)

[puremourning]

perhaps you're right technically. I think in practice it can, kinda, (and my client indeed does) because in practice, most servers don't respond to the execute command until it finished sending edits.
but tbh this is one of the many reasons why I think the "execute command" interface is wonky and difficult to implement correctly. It's not OK for a server to be sending edits to the client willy-nilly when the user isn't expecting them; the user would rightly be frustrated if they are interupted in their work by such an unsolicited workspace edit.

Anyway, that's probably aside. Adding additional metadata to the workspaceEdit doesn't seem all that controversial now that I think about it :)

[DanTup]

because in practice, most servers don't respond to the execute command until it finished sending edits.

This is not something defined by the spec, so if clients are doing this, I think it should be made clear. Any behaviour (by server or client) that isn't specified could easily lead to some LSP clients/servers not working correctly together (or being intermittent - for example if the behaviour you see today is just random chance because of timing rather than a deliberate choice).

but tbh this is one of the many reasons why I think the "execute command" interface is wonky and difficult to implement correctly. It's not OK for a server to be sending edits to the client willy-nilly when the user isn't expecting them; the user would rightly be frustrated if they are interupted in their work by such an unsolicited workspace edit.

I agree, workspace/applyEdit always felt slightly odd to me. But it's the only way to implement a number of things that are driven by commands (for example one command I'd like to add is the ability to run "dart fix" for your workspace... it's not a single file, so it doesn't belong in the Source CodeActions, but it will produce a bunch of edits which I'd like to use AnnotatedEdits for with a preview).

I feel like it would be nice if Commands could conditionally return WorkspaceEdits because that's probably the only place (besides CodeAction) I can come up with where you would reasonably call workspace/applyEdit, and then it's absolutely clear that it's an edit for that command.

[puremourning]

would be nice if Commands could conditionally return WorkspaceEdits

100% agree. In the same way that codeActions can supply literals, so should commands.

[KamasamaK]

(I assume this is the reason VS Code added it, and didn't just use the CodeActionKind, but I don't know - I just saw it in the release notes and figured it was something we should adopt in our LSP server to match).

The associated issue for that new feature is microsoft/vscode#112109