rust-analyzer icon indicating copy to clipboard operation
rust-analyzer copied to clipboard

VSCode now supports SnippetTextEdits natively

Open Veykril opened this issue 2 years ago • 3 comments

We should switch to that microsoft/vscode#145374 (comment), https://github.com/rust-lang/rust-analyzer/issues/13213#issuecomment-1245399078

Veykril avatar Sep 13 '22 13:09 Veykril

I assume this has to wait until the October release is out, if we want to support N-1 versions of VS Code?

jonas-schievink avatar Sep 14 '22 14:09 jonas-schievink

I suppose so? I don't really remember out stance in regards to required VSCode version, but waiting for october sounds reasonable

Veykril avatar Sep 14 '22 14:09 Veykril

It's complicated. We've mostly supported more versions lately when someone at a FAANG asked for that. But they're using a fork of both Code and RA anyway, and I haven't heard much about their rebase schedule lately.

lnicola avatar Sep 14 '22 15:09 lnicola

I guess we could revisit this now? I skimmed the links, but it's not clear to me how well the new Code API matches our extension.

lnicola avatar Mar 13 '23 17:03 lnicola

It's complicated. We've mostly supported more versions lately when someone at a FAANG asked for that. But they're using a fork of both Code and RA anyway, and I haven't heard much about their rebase schedule lately.

I'm decently sure that I'm the person in question. In any case, feel free to revisit this now: the sibling team responsible should rolling 1.75 in a few days. I might just ask that https://github.com/rust-lang/rust-analyzer/pull/14307 land before your changes land, it'd make the rebase/patching a bit easier on my end (I'm assuming #14307 will land this week).

davidbarsky avatar Mar 13 '23 21:03 davidbarsky

I guess we could revisit this now? I skimmed the links, but it's not clear to me how well the new Code API matches our extension.

Unfortunately, the major difference is that the Code API (along with the related snippet APIs) performs whitespace fixups, and since we preserve the the original whitespace, this leads to extra indentation (see https://github.com/microsoft/language-server-protocol/issues/724#issuecomment-631558796). There also currently isn't a way to disable these fixups for SnippetTextEdits.

Thankfully, normal TextEdits insert the text as-is, so a workaround could be to isolate snippets to their own SnippetTextEdits and use TextEdits for everything else. This is definitely achievable with the structured snippet API (since it keeps track of where snippets need to be placed), though most assists don't use it yet. Finding where snippets are in TextEdits are is also an option, though that would require having to add a parser to find the exact locations of snippets.

A minor issue of this workaround is that this would technically go against the current specification of the snippetTextEdit extension (see #13213), although changing the definition of the spec seems to be preferred option (if I'm interpreting this comment right). Changing it also permits the user to immediately rename generated items by using multiple placeholder snippets in the same tabstop (which would be a way of solving https://github.com/sublimelsp/LSP-rust-analyzer/issues/49).

In summary, we probably can't revisit this soon until we can work around the whitespace fixups.

DropDemBits avatar Jun 04 '23 23:06 DropDemBits