Support to resolve code actions

[jrieken]

Todays API for code actions wants all actions to be returned fully resolved, e.g the command or edit must be set. For some code action providers that's not easy and the usual "workaround" is to move the heavy lifting into the command (instead of using workspace edits). However, with commands it's harder to control the overall experience, like undo-stack or previewing changes.

The proposed change below adds a resolveCodeAction function to code action provider which the editor would call before applying a code action.

export interface CodeActionProvider<T extends CodeAction> {
  provideCodeActions(document: TextDocument, range: Range | Selection, context: CodeActionContext, token: CancellationToken): ProviderResult<(Command | T)[]>;

  // NEW - allow to fill in things like edit or command
  resolveCodeAction(action: T, token: CancellationToken): ProviderResult<T>;
}

fyi @dbaeumer since this exists in LSP already

[mjbvz]

Would resolve only be called when the user selects a code action? Or would it behave like for suggestions where we try resolving entries as you arrow through the code action list?

[jrieken]

Right now I would say only when selecting a code action. We have all information to render a list of code actions but for the future. Who knows... VS has a feature where focusing a code action already shows a hover with the diff of the changes...

[mjbvz]

That sounds good. The one complication is that we currently use native context menus for code actions. I'll have to check to see if we can detect when the user changes the active item in a native context menu

Related: I've wanted to switch to use UI for code actions for a long time but have never had the time to look into this

[dbaeumer]

Will we always call resolve even if command or edit ?

[jrieken]

No, I'd say only when needed, e.g when not having an edit or command. It's a little ambiguous because edit or command can be set...

[dbaeumer]

I am in favor of this.

[jrieken]

Work on this has started in #106856. I have implemented the following

• old school providers that return commands, not code actions, cannot use resolve
• resolve only allows to fill in the edit. A command is easy to provide upfront and we actually want authors to provide edits

[jrieken]

@dbaeumer the proposal is now in master and ready to use

[testforstephen]

A good proposal. I see the Java language server can benefit from the lazy resolve idea.

Currently when editing a big Java file (e.g. 5k+ lines), it will cause the Java language server to take much CPU time to calculate the workspace edits for all code action proposals such as quickfix, refactoring, source action. For some resource-constrained machines, this affects the processing of other requests. In particular, it may cause the codeCompletion handler waiting for resources to run, and slow down code completion performance.

@jrieken when it's ready in insider, i'd like to have a try to see how it goes.

[mjbvz]

@jrieken I adopted this for JS/TS refectorings in 5a7d0a1 (also made a small fix to the VS Code implementation)

We still need to use a command to trigger a rename after extracting a method or constant but this new API simplified the implementation.

[jrieken]

Thanks @mjbvz

[dbaeumer]

@jrieken thanks!

[jrieken]

This is now finalized

[dbaeumer]

@jrieken just to be sure. It is out of proposed state. Right ?

[jrieken]

Yeah - as final as it gets

[dbaeumer]

Great!

[testforstephen]

A quick question here.

I see codeAction/resolve is already added into lsp 3.16. Does VS Code client already adopt the spec? // cc: @jrieken @dbaeumer

[jrieken]

yes. it is in current insiders and next stable

[testforstephen]

thank you @jrieken.

I tried the latest insider at 09-29, looks like the initialize request from vscode client doesn't carry the clientCapability for textDocument.codeAction.resolveSupport.

Below is the codeAction capability from LSP initialize params. It doesn't declare the codeAction/resolve support.

{
  "capabilities": {
   ...
   "textDocument": {
         "codeAction": {
                "dynamicRegistration": true,
                "isPreferredSupport": true,
                "codeActionLiteralSupport": {
                    "codeActionKind": {
                        "valueSet": [
                            "",
                            "quickfix",
                            "refactor",
                            "refactor.extract",
                            "refactor.inline",
                            "refactor.rewrite",
                            "source",
                            "source.organizeImports"
                        ]
                    }
                }
            },

[jrieken]

🤷 idk - that's LSP, not VS Code. Ping @dbaeumer for what version of the LSP client supporting this