Add CodeAction class

[mjbvz]

VS Code 1.20 adds a new CodeAction type that captures additional information about codeactions:

• https://github.com/Microsoft/vscode/blob/b5e2d0a6bcbae4f71099715dc813239d21975eb5/src/vs/vscode.d.ts#L1897
• https://github.com/Microsoft/vscode-docs/blob/vnext/release-notes/v1_20.md#codeactionprovider-improvements

This new type is used by several new product features such as the Refactor command and the editor.action.codeAction command. It should also be supported in the LSP for code action provides

[yaohaizh]

Second this. @aeschli

Current, the lsp CodeAction return a list of Command. It is hard to differentiate these commands. In test cases, we need do some filter based on the commands.

[gorkem]

+1
I think the WorkspaceEdit field is also an improvement on the references object. Most code actions are just workspace edits and some LSPs are doing a round trip for no good reason other than specification's short comings.

[mickaelistria]

Seems very similar to proposal in #178

[dbaeumer]

See also the discussion in #432. We should work on this sooner than later since it will make things a lot easier to understand when it comes to commands and code actions.

[rcjsuen]

New OrganizeImports CodeActionKind being considered, see microsoft/vscode#47845.

[mjbvz]

I just merged in the OrganizeImports addition from microsoft/vscode#47850. From the API perspective, all it did was add a new constant.

I'd like to get other extensions that have their own organize imports (such as java) to try to migrate over to using a code action instead. This is blocked until we have basic support for a CodeAction class in the LSP

[mickaelistria]

I would like to work on this, however I've got some preliminary questions:
Does the proposal for the spec have to follow the current class in VSCode? I'm not convinced we need to specify the codeActionKind from 1st round, and I also find more correct for the protocol to clearly use Command|WorkspaceEdit explicitly instead of having 2 distinct field and a comment saying they're exclusive.
Also, should the protocol add some client/server capability to declare what kind of codeActions results are expected/supported (current command-only as default value, codeAction class as an option)? Or can we just move it forward and let clients implement some tricks for backward compatibility (LSP4J is good at it as it can have the request return an Either<Command[]|CodeAction[]> for the codeAction request, which is IMO simpler to use than capabilities to decide of how to handle the response).

[mjbvz]

The kind is a big reason we added the CodeAction class.VS Code uses it split code actions by type in order to create different menus for refactoring actions and source action, and I imagine other tools will want to do something similar.

The command and edit actually aren't implemented as exclusive. We apply the command and then the command. I'll update the vscode docs to make this clear.

One other point: we also added an only field to CodeActionContext. This is used to say which types of code actions a code action provider should return.

[dbaeumer]

Actually this got added to the VS Code May plan :-).

@mickaelistria I still appreciating your help here. I will have a look beginning of next week and then add a proposal how I think we can best implement this. Knowing that the Java implementation solved this with an Either type I am actually leaning towards having this as or types in the spec.

[dbaeumer]

Here is a PR for a CodeAction type in the protocol: microsoft/vscode-languageserver-node#350

Clients need to opt into allowing textDocument/codeAction requests returning CodeAction literals. In addition the kind value set is announced by the client as well.

Feedback welcome.

[yaohaizh]

@dbaeumer microsoft/vscode-languageserver-node#350 is merged. When will the vscode language server protocol spec will be updated?

[dbaeumer]

@yaohaizh sorry. Forgot about it in the endgame stress. Will do today.

[mickaelistria]

Thank you very much!

[dbaeumer]

You are welcome.

[Gama11]

I was having some trouble getting the "Organize Imports" command and "Source Action..." context menu item to show up in VSCode after implementing CodeActionKind.SourceOrganizeImports in the Haxe Language Server (despite it working fine with "editorCodeActionsOnSave"). After some digging, I stumbled over this in the 1.23 release notes:

https://code.visualstudio.com/updates/v1_23#_codeactionprovidermetadata

So if I understand correctly, a language server currently can't have proper "Organize Imports" support in VSCode because CodeActionProviderMetadata is missing from the protocol? The same would apply to the Refactor... menu. Or am I missing something?

[mjbvz]

@Gama11 Was this the same problem you were seeing with microsoft/vscode#54803 ?

[Gama11]

No, both have to do with Code Action kinds, but this is unrelated.

Basically, the Language Server Protocol is missing a way to for the server specifiy what kinds of code actions will be provided (CodeActionProviderMetadata), meaning you can't get these context menu items (and the "Organize Imports" command) to show up in VSCode:

This is documented in the 1,23 release notes which I linked to earlier. I would have expected this to be part of ServerCapabilities, but codeActionProvider is still just a simple boolean right now. As a result, the registerCodeActionProvider() call in vscode-languageclient is not providing this metadata.

[Gama11]

• Add CodeActionOptions with providedCodeActionKinds #534
• Add CodeActionOptions with providedCodeActionKinds vscode-languageserver-node#385