Bracket Completion and Autoclosing API

[juihanamshet1]

A common issue users have brought up when using whole line completions is that if the completion has open brackets, they are not auto-closed when the user accepts the completion. Users depend upon VS Code's bracket autoclosing and when they don't experience the same when using whole line completions, it deteriorates their user experience.

To allow us to show whole line completions and reliably have balanced brackets, we'd like the ability to interact with the bracket auto-closing API which we can use to close open brackets inserted in a whole line completion.

This is how we achieve the same in Visual Studio:

1. We provide a whole line completion containing an open parenthesis in the end
   

2. When the user accepts the completion, we start a brace completion session for the open parenthesis. The open paren is then closed by the language service and the cursor is placed in between the open and close paren.
   

If the user opens a brace inside quotation, it doesn't start a brace completion session and hence, is not auto-closed.

Based on our experience with implementing this in Visual Studio, we'd need the below functionality in the API:

• Be able to look at the stack of bracket completion sessions; this will allow us to remove any unbalanced parenthesis introduced by whole line completions.
• Be able to simulate the user typing characters so that a brace completion session can be started which will tell language service to return the closing brace

(cc @hediet)

[juihanamshet1]

Hi, I wanted to check in if you had any follow-up questions or updates on this issue. Please let me know if I can provide more information.

[hediet]

I have the ticket on my radar, but I need to finish something else first. I will get back to it!

[hediet]

Be able to look at the stack of bracket completion sessions; this will allow us to remove any unbalanced parenthesis introduced by whole line completions.

I doubt it will be easy/possible to expose this to the extension host.
Do you have an example of which bracket you want to remove?

Be able to simulate the user typing characters so that a brace completion session can be started which will tell language service to return the closing brace

I also doubt this will be easy.

---

From my understanding, these are some examples (| indicating the final cursor position):

Model Output => Actual Insert Text

• Console.WriteLine( => Console.WriteLine(|)
• Console.Write({ => Console.Write({|})
• Console.Write("{" => Console.Write("{"|)
• Console.Write()) => Console.Write() (Did I get that right?)

I could imagine that each provided inline completion item could have a flag completeBrackets: boolean that you could set to true (default false).
If set, VS Code will try to insert any missing brackets when the inline completion is about to be committed.
What do you think about that?

Also, as we already are late into the november iteration, I will move this to the december milestone, if you are okay with that.

[juihanamshet1]

Thank you for the detailed response! The idea of setting the completeBrackets flag and for VS Code to perform bracket completion sounds good to us. We have the below clarifying questions:

1. When you perform bracket completion, will it be for the completion in isolation or for the whole document including the completion? There are a few examples where the completion provides closing paren that already exist in the document.

• In this example, will the completion be suppressed because the open curly brace in line 1 is already closed in line 4?
  
• In the below examples, the two closing curly braces should be removed but the , should remain
  
  
• Same for this example, the ) { should be removed
  

2. Will the brace completion happen before the completion is shown to the user? I.e. in the examples shown in your response, will the grey text be the model output or the actual insert text?

[hediet]

Thanks for the details!

It would be awesome if you could specify some tests.
Ideally in this format (note that it uses the unicode characters ⟦, ⟧, ⦅ and ⦆ to avoid confusion with actual brackets and ‖ for the cursor):

test(`
const {
    bestCompletion: completion,
    metadata: {
        firstTokenScore,
        ⟦⟧⦅tokenCount},}⦆
    },
} = this.completionState.getLineCompletion();
`, `tokenCount,‖`);

test(`⟦⟧⦅console.log(⦆`, `console.log(‖)`);

...

Please use test("...⟦x⟧⦅y⦆...", "z"); where x refers to the text to replace (must be single-line), y to the text to insert (can be multi-line) and z to the massaged text to insert instead with correct braces. Use ‖ to indicate the cursor position in z.

Your extension can provide x through the replace range and y as text to insert. VS Code will then preprocess that inline suggestion and use z as text to insert instead.

My idea is to both show and insert z rather than y. Thus, bracket completion is a preprocess step that the extension could have done (in theory) on its own.
Only the feature of cursor placement is new.

---

Just being curious, what is the reasoning of why you want to keep that comma in your second example? Isn't this just luck that it works?
Let's say TypeScript would use ; as separator in objects and , as separator in arrays. Consider this:

const [
    completion,
    {
        firstTokenScore;
        cumulativeLastScore;
        ⟦⟧⦅tokenCount},}⦆
    },
] = this.completionState.getLineCompletion();

After brackets are stripped from tokenCount},}, you end up with tokenCount,.

It makes sense for the model to initially suggest a ,, as the closing bracket enters the array-destructure expression again, where commas are used.
But if you remove the brackets, that comma does not make sense anymore, as a semicolon is expected in that context.

[hediet]

@Krzysztof-Cieslak @orph you might also be interested in this, though this will definitely be an opt-in feature. But I noticed that copilot still often inserts unbalanced brackets.

[Krzysztof-Cieslak]

CC: @hsenag

[hsenag]

I agree that Copilot often gets brackets wrong and that better cooperation with the editor could help us do better.

Would completeBrackets:true both remove excess brackets and add missing brackets to the completion? How would it behave if the code without the completion already has mismatched or unbalanced brackets?

CC: @SmallLemur :-)

[juihanamshet1]

Thank you for the tests format, apologies for the delay! I've included a file with some tests. Let me know if you have any follow-up questions on the tests.

vscode_wlc_brace_completion_tests.txt

I have the following questions:

1. For Test 7, do you think it would be possible to add the missing open paren or would you remove the extra closing paren?

2. For Test 11 and 13 which requires multiple closing braces to be added, what would be the behavior of bracket autoclosing that already exists in VS Code and the new brace completion you'll implement? Let's say x = console.log(, y = console.log((1, and z = console.log((1)). If the user is walking over the prediction i.e. typing the same characters as the prediction, when the user types that first open paren, the existing bracket autoclosing will insert a closing paren. Which of the two closing brackets in z would be white instead of grey? Would it be the second closing bracket?

3. If the user is walking the prediction, we basically keep returning the same prediction but truncated depending on how much the user has walked. This would trigger brace completion step for the same prediction, will there be a performance impact?