Virtual Method

LspServercode_action_async

Declaration

void
code_action_async (
  LspServer* self,
  LspClient* client,
  LspTextDocumentIdentifier* text_document,
  LspRange* range,
  LspCodeActionContext* context,
  GAsyncReadyCallback _callback_,
  void* _callback__target
)

Description

The code action request is sent from the client to the server to compute commands for a given text document and range. These commands are typically code fixes to either fix problems or to beautify/refactor code. The result of a textDocument/codeAction request is an array of Command literals which are typically presented in the user interface. To ensure that a server is useful in many clients the commands specified in a code actions should be handled by the server and not by the client (see workspace/executeCommand and ServerCapabilities.executeCommandProvider). If the client supports providing edits with a code action then that mode should be used.

Since version 3.16.0: a client can offer a server to delay the computation of code action properties during a ‘textDocument/codeAction’ request:

This is useful for cases where it is expensive to compute the value of a property (for example the edit property). Clients signal this through the codeAction.resolveSupport capability which lists all properties a client can resolve lazily. The server capability codeActionProvider.resolveProvider signals that a server will offer a codeAction/resolve route. To help servers to uniquely identify a code action in the resolve request, a code action literal can optional carry a data property. This is also guarded by an additional client capability codeAction.dataSupport. In general, a client should offer data support if it offers resolve support. It should also be noted that servers shouldn’t alter existing attributes of a code action in a codeAction/resolve request.

Since version 3.8.0: support for CodeAction literals to enable the following scenarios:

the ability to directly return a workspace edit from the code action request. This avoids having another server roundtrip to execute an actual code action. However server providers should be aware that if the code action is expensive to compute or the edits are huge it might still be beneficial if the result is simply a command and the actual edit is only computed when needed.
the ability to group code actions using a kind. Clients are allowed to ignore that information. However it allows them to better group code action for example into corresponding menus (e.g. all refactor code actions into a refactor menu).

Clients need to announce their support for code action literals (e.g. literals of type CodeAction) and code action kinds via the corresponding client capability codeAction.codeActionLiteralSupport.