Postfix snippets no longer work in vscode

[jtraub]

rust-analyzer version: 0.4.1909-standalone

editor or extension: VSCode with extension v0.4.1909 (pre-release)

Postfix snippets stopped working after I've updated vscode extension.

After downgrading a few times I found that the last version that has postfix snippets working is v0.4.1908. Upgrading it to v0.4.1909 breaks them.

v0.4.1908

v0.4.1909

[yiyueawa]

me too

[roife]

Possibly related to #17000.

That's strange since it works fine on emacs (eglot) 🤔

[facefaceless]

Magic completion dosen't show up in the completion list too after upgrading to a newer version.
I use vscode on windows, and RA 0.3.1906 (release version) is the newest version that works fine for me.
Maybe they are the same problem.

[roife]

@rustbot claim

I've identified the problem. For illustration, let's use the following example:

1 . o k
^ ^ ^ ^ ^
0 1 2 3 4

Before #17000, r-a would send TextEdit delete 2..4, insert Ok(1) to the editor within CompletionItem. After the change, r-a would send delete 0..4, insert Ok(1).

But in VS Code, the starting position for TextEdit replace cannot precede the completion position (i.e., cannot precede 2), and VS Code automatically filters out items that violate it.

Currently, I've thought of several solutions:

1. Delete 0..2 in additionalTextEdit, then TextEdit still sends delete 2..4, insert Ok(1). I've tried it and this fixes the problem in VS Code, but it seems that helix does not yet support additionalTextEdit.
2. Revert c5686c8.
3. Apply special handling for VS Code (a bit dirty). 🤔

I would prefer the second solution.

[kericsson-dotnet]

Postfix snippets seems to be broken in Neovim as well. Working fine in 2024-04-01, not showing up in 2024-04-08

[pascalkuthe]

. I've tried it and this fixes the problem in VS Code, but it seems that helix does not yet support additionalTextEdit

Helix fully support additionalTextEdits. We just dont preview them since we expect them to not be associated with the cursor. Quote from the LSP spec:

Additional text edits should be used to change text unrelated to the current cursor positition

So we only apply additionalTextEditd when accepting a completion. Qhile the lossy in preview is a bit annoying it's not that big of a deal.

The real problem is that these kinds of edits do not work with multicursor completions. You can map the main completion edit to each cursor (by computing relative positions to the curosr). But you can't do that with additonalTextEdit Since they are meant for edits not associated with the cursor (like imports) that should not be repeated for each cursor.

These edits are perfectly valid according to the LSP spec. The spec says the completion position must be contained within the edit but not that it must start exactly at the cursor:

The range of the edit must be a single line range and it must contain the position at which completion has been requested

The reason this gets filtered is not that vacode filters out all edits that precede the cursor position. The reason is that vscode uses the replace range for filtering so to take the example from above if the edit replaces 1.ok with Ok then vscode filters that with 1.ok and sincr the filter text doesnt contain 1. it gets filtered out (which is spec compliant and what I am working on moving helix towards).

The right way to fix this issue in a spec compliant manner is to adjust the filter text of these completions to include the prefix they are replacing

[Veykril]

So, we should be able to change the replace range here if we also fix up the filter text used for postfix completions. Then VSCode should be happy as well?

[pascalkuthe]

So, we should be able to change the replace range here if we also fix up the filter text used for postfix completions. Then VSCode should be happy as well?

Exactly, sorry my comment wasn't perfectly clear. I didn't have my first coffee yet.

In fact RA already does exactly that for other edits I think (there are some edits which replace the word the cursor is in. These also replace text before the curosr and they work in VSCode because they set the filtertext correctly.

I was planning to do a PR that implements what I describe once I have some freetime. That should fix the problems we are seeing in helix while also making sure that the completions don't get filtered out in VSCode