diff options
author | bors[bot] <26634292+bors[bot]@users.noreply.github.com> | 2020-05-22 16:33:12 +0100 |
---|---|---|
committer | GitHub <[email protected]> | 2020-05-22 16:33:12 +0100 |
commit | 2a36a2a3cc016de61a5df3165037ed689f36c423 (patch) | |
tree | bc08c40bd490c35a76bfd6849b6c372f0ab8311a /docs/dev/lsp-extensions.md | |
parent | 0fb71349156619e26a15ae21d7730eb9ce020446 (diff) | |
parent | 2075e77ee5784e72396c64c9ca059763508219ff (diff) |
Merge #4569
4569: CodeAction groups r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <[email protected]>
Diffstat (limited to 'docs/dev/lsp-extensions.md')
-rw-r--r-- | docs/dev/lsp-extensions.md | 49 |
1 files changed, 47 insertions, 2 deletions
diff --git a/docs/dev/lsp-extensions.md b/docs/dev/lsp-extensions.md index 7c45aef4c..d90875f8b 100644 --- a/docs/dev/lsp-extensions.md +++ b/docs/dev/lsp-extensions.md | |||
@@ -5,7 +5,7 @@ It's a best effort document, when in doubt, consult the source (and send a PR wi | |||
5 | We aim to upstream all non Rust-specific extensions to the protocol, but this is not a top priority. | 5 | We aim to upstream all non Rust-specific extensions to the protocol, but this is not a top priority. |
6 | All capabilities are enabled via `experimental` field of `ClientCapabilities`. | 6 | All capabilities are enabled via `experimental` field of `ClientCapabilities`. |
7 | 7 | ||
8 | ## `SnippetTextEdit` | 8 | ## Snippet `TextEdit` |
9 | 9 | ||
10 | **Client Capability:** `{ "snippetTextEdit": boolean }` | 10 | **Client Capability:** `{ "snippetTextEdit": boolean }` |
11 | 11 | ||
@@ -36,7 +36,7 @@ At the moment, rust-analyzer guarantees that only a single edit will have `Inser | |||
36 | * Where exactly are `SnippetTextEdit`s allowed (only in code actions at the moment)? | 36 | * Where exactly are `SnippetTextEdit`s allowed (only in code actions at the moment)? |
37 | * Can snippets span multiple files (so far, no)? | 37 | * Can snippets span multiple files (so far, no)? |
38 | 38 | ||
39 | ## `joinLines` | 39 | ## Join Lines |
40 | 40 | ||
41 | **Server Capability:** `{ "joinLines": boolean }` | 41 | **Server Capability:** `{ "joinLines": boolean }` |
42 | 42 | ||
@@ -119,3 +119,48 @@ SSR with query `foo($a:expr, $b:expr) ==>> ($a).foo($b)` will transform, eg `foo | |||
119 | 119 | ||
120 | * Probably needs search without replace mode | 120 | * Probably needs search without replace mode |
121 | * Needs a way to limit the scope to certain files. | 121 | * Needs a way to limit the scope to certain files. |
122 | |||
123 | ## `CodeAction` Groups | ||
124 | |||
125 | **Client Capability:** `{ "codeActionGroup": boolean }` | ||
126 | |||
127 | If this capability is set, `CodeAction` returned from the server contain an additional field, `group`: | ||
128 | |||
129 | ```typescript | ||
130 | interface CodeAction { | ||
131 | title: string; | ||
132 | group?: string; | ||
133 | ... | ||
134 | } | ||
135 | ``` | ||
136 | |||
137 | All code-actions with the same `group` should be grouped under single (extendable) entry in lightbulb menu. | ||
138 | The set of actions `[ { title: "foo" }, { group: "frobnicate", title: "bar" }, { group: "frobnicate", title: "baz" }]` should be rendered as | ||
139 | |||
140 | ``` | ||
141 | 💡 | ||
142 | +-------------+ | ||
143 | | foo | | ||
144 | +-------------+-----+ | ||
145 | | frobnicate >| bar | | ||
146 | +-------------+-----+ | ||
147 | | baz | | ||
148 | +-----+ | ||
149 | ``` | ||
150 | |||
151 | Alternatively, selecting `frobnicate` could present a user with an additional menu to choose between `bar` and `baz`. | ||
152 | |||
153 | ### Example | ||
154 | |||
155 | ```rust | ||
156 | fn main() { | ||
157 | let x: Entry/*cursor here*/ = todo!(); | ||
158 | } | ||
159 | ``` | ||
160 | |||
161 | 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. | ||
162 | |||
163 | ### Unresolved Questions | ||
164 | |||
165 | * Is a fixed two-level structure enough? | ||
166 | * Should we devise a general way to encode custom interaction protocols for GUI refactorings? | ||