Completions in VS Code

[zachallaun]

The following improvements cannot be made until related issues in VS Code are resolved:

• Don't emit noisy, largely useless completions for single-character atom and local prefixes in VS Code.
  • Support CompletionList.isIncomplete=true on empty lists (or at least, clearly document current behaviour) microsoft/vscode#155738
• Use isIncomplete=true to include more/less completions based on context as the user types.
  • Filter completion client-side even if the LSP returns incomplete results microsoft/vscode#168329
  • CompletionList.isIncomplete=true results in showing "stale" results when typing quickly due to cancelled requests microsoft/vscode#147830

---

While doing some work on completions, I found a number of VS Code issues that affect completions pretty significantly. The workarounds for these may need to occur both here and in lexical-lsp/vscode-lexical, so I'm creating a single tracking issue to consolidate information for now.

---

When a completion request is issued by the client, the response from the server can optionally set an isIncomplete flag. If it's set to true, according to the spec¹: "This list is not complete. Further typing should result in recomputing this list." This means that further typing could add/reorder items.

Without isIncomplete set to true, VS Code makes the assumption that the initial set of items is complete, and further characters in the same "word" are filtered client-side. This means that for each word, only a single completion request will be issued. This led to some completions never appearing in VS Code, fixed by #398.

Unfortunately, this fix isn't complete: VS Code has what I think must be considered a bug²: If a completion result is empty, i.e. the list of completion items is [], even if isIncomplete is set to true, VS Code will not issue additional completion requests. So if we return no completions on the first character, VS Code will never show additional completions from the server.

There have been additional issues and suggestions³⁴ for how VS Code's behavior should be improved, but I think all of them hinge on the original bug being resolved.

---

Looking through the linked issues, multiple language servers have tried various workarounds. For now, however, it may be necessary to move away from using isIncomplete if possible and always return the full set of completions on the first character.

Footnotes

1. LSP Specification: textDocument/completion ↩

2. Support CompletionList.isIncomplete=true on empty lists (or at least, clearly document current behaviour) microsoft/vscode#155738 ↩

3. Filter completion client-side even if the LSP returns incomplete results microsoft/vscode#168329 ↩

4. CompletionList.isIncomplete=true results in showing "stale" results when typing quickly due to cancelled requests microsoft/vscode#147830 ↩

[scottming]

I found that the fix in PR #398 has caused some new issues. In my understanding, is_incomplete: true means that the server did not return all the data, and the client needs to continue making requests. This leads to more frequent communication between them and complicates the situation.

For example, in Neovim, there is now frequent flickering when completing structs, which was not the case before.

now

CleanShot.2023-10-14.at.15.18.49.mp4

Before(Better UX)

CleanShot.2023-10-14.at.15.16.52-converted.mp4

Regarding the thing you mentioned in reference [^2], I also think it is a bug because other clients can handle this aspect well. Therefore, I also think we should not return all completion results in the same format with Completion.List.new(items: items, is_incomplete: true).

[zachallaun]

You're correct, @scottming -- this is a UX regression from #398. If we start returning completions for single-character prefixes (#410 does this for all completions except atoms), we can revert #398.

The problem is that, for VS Code, it seems to be all or nothing: return all possible completions on the first character, or no completions will be shown at all for subsequent input until a trigger character or new word is seen.

[zachallaun]

Behavior in VS Code was much improved by #410, but I'd like to leave this issue open to make it hopefully easier to track the upstream issues in VS Code and as context for people coming here to report other potential issues with VS Code completions.

[scohen]

@zachallaun I don't like long-lived issues, unless they're tracking several sub-issues. Can we either close this or provide a set of tasks that when completed would close this issue?

[zachallaun]

@scohen There are (at least) 2 features we can't have, at least for VS Code, until related issues are resolved. I added them to the top of the OP.

[scohen]

Thank you!