TS Server API proposal: Commit Characters

[mjbvz]

Problem

VS Code (and Visual Studio) have the concept of commit characters for suggestions. This is a set of characters that, when typed, accept the current suggestion. For example, a suggestion for a function may treat ( as a commit character.

VS Code currently computes these commit characters itself using the metadata that typescript returns for each completion entry. This has two problems:

• This logic is VS Code specific and may be out of sync with how VS and other editors handle commit characters.

• There are some cases where it is difficult to determine what the commit characters should be. A classic example is:

const a = {
    b: 1,
    .|
}

Where the user has just typed .. Currently we show a suggestion for b when the user types the .. If the user then types another . as part of a spread, we incorrectly end up accepting that completion, which leaves the code as:

const a = {
    b: 1,
    .b.
}

TypeScript, with its access to the ast, should be able to determine that . should not be a commit character in this case

Proposal

Introduce the concept of a commit characters to the TypeScript server aAPI. This would be an optional set of characters returned on each CompletionEntry:

 interface CompletionEntry {
     ...

     commitCharacters?: ReadonlyArray<string>;
}

Return these commit characters on completions. Here's an approximation of how VS Code computes commit characters:

• . and ; are commit characters for most completion types except for keywords and a few others.
• Additionally, ( and , are commit characters for variables.
• There are no commit characters if isNewIdentifierLocation is set.

[mjbvz]

If there is concern about the cost of computing the commit characters or about returning them on every suggestion, we can return them on CompletionEntryDetails instead.

[DanielRosenwasser]

Something to keep in mind (which I think we've discussed) is the fact that some of the motivating scenarios are just plain bugs (e.g. maybe we shouldn't be providing completions after . in an object literal). Maybe #31244 is a better one, but it doesn't seem like the rules listed here would apply to that.