Code Action Groups

[matklad]

Another general protocol extension poached from rust-analyzer

CodeAction Groups

Client Capability: { "codeActionGroup": boolean }

If this capability is set, CodeAction returned from the server contain an additional field, group:

interface CodeAction {
    title: string;
    group?: string;
    ...
}

All code-actions with the same group should be grouped under single (extendable) entry in lightbulb menu. The set of actions [ { title: "foo" }, { group: "frobnicate", title: "bar" }, { group: "frobnicate", title: "baz" }] should be rendered as

💡
  +-------------+
  | foo         |
  +-------------+-----+
  | frobnicate >| bar |
  +-------------+-----+
                | baz |
                +-----+

Alternatively, selecting frobnicate could present a user with an additional menu to choose between bar and baz.

Example

fn main() {
    let x: Entry/*cursor here*/ = todo!();
}

Invoking code action at this position will yield two code actions for importing Entry from either collections::HashMap or collection::BTreeMap, grouped under a single "import" group.

Unresolved Questions

• Is a fixed two-level structure enough?
• Should we devise a general way to encode custom interaction protocols for GUI refactorings?

IntelliJ variation:

[puremourning]

What's the motivation for this over just having frobicate Bar and frobnicate Baz as options?

[matklad]

Just having two options wouldn't be too bad, and that's what clients not supporting groups get!

However, grouping has two benefits:

• it keeps the total number of available code actions lower (and that's important because the number of available actions would be pretty large for mature servers).
• it makes it easier to the user to choose the right action, because they are presented with sub-choices only after they decided that they want this action in the first place.

[kjeremy]

I almost feel like this could be solved using some clever display logic around the hierarchical nature of CodeActionKind.

[dbaeumer]

@kjeremy good point. VS Code for example allows triggering Source and Refactor actions via a separate menu action.

However making this explicit most of the time results in better UI in the longer term.

[michaelmesser]

Would the second level be resolved only once the user accesses it?

[michaelmesser]

I propose adding the ability for servers to:

• request the user enter arbitrary text with a modal
• request the user pick an option with a modal

Then a code action command would trigger the server ask the user for an option. This seems more flexible than code action groups.

[heejaechang]

VS already supports code action group. it would be nice to include this in LSP so that we can use group at least in VS. and ask for group support in vscode.

for example, LSP has streaming support that we use in VS, but vscode doesn't support it yet (except in a few places I believe)

[heejaechang]

by the way, here is how API looks like in VS - https://learn.microsoft.com/en-us/dotnet/api/microsoft.visualstudio.language.intellisense.isuggestedaction?view=visualstudiosdk-2022

basically, each code action can be invoked (executed) or/and can return nested actions.