More specific kind name for Code Action items

This is feature request.

Problem

When running Code Action, rust-analyzer returns list of actions like below:

[
  {
    "edit": {
      snip...
    },
    "kind": "quickfix",
    "title": "Import `std::io`"
  },
  {
    "edit": {
      snip...
    },
    "kind": "quickfix",
    "title": "Qualify as `std::io`"
  },
  {
    "edit": {
      snip...
    },
    "kind": "refactor.extract",
    "title": "Extract into function"
  }
]

With this list, it is not possible to filter only import fix by kind. kind is used to filter actions, but some actions have the same kind so they cannot be filtered. LSP v3.16 says:

	/**
	 * The kind of the code action.
	 *
	 * Used to filter code actions.
	 */
	kind?: CodeActionKind;

and vim-lsp's :LspCodeAction provides the way to filter actions by kind:

LspCodeAction [{CodeActionKind}]                            *:LspCodeAction*

Gets a list of possible commands that can be applied to a file so it can be
fixed (quick fix).

If the optional {CodeActionKind} specified, will invoke code action
immediately when matched code action is one only.

I want to specify more specific kind for actions, for example filtering only import actions so that I can easily run specific action for current cursor position without selecting item from list.

Solution

gopls uses kind names which can be distinguished like source.organizeImports for organizing imports.

I want to suggest more specific kind name separated by . for example:

• quickfix.import for adding import statement
• quickfix.qualify for completing module name qualifier

If this idea looks good, I want to try to make a PR for this issue.

Environment

• rust-analyzer: d54e115
• LSP client: vim-lsp
• OS: macOS 10.15

Start by locating rust-analyzer's Code Action generation and the handling of LSP CodeAction.kind; the issue provides no file or test names. Compare the proposed quickfix.import and quickfix.qualify naming with the LSP v3.16 specification and the gopls example, then identify how filtering should distinguish these actions. Done means the relevant actions expose specific kinds and coverage verifies the resulting behavior.