Partial suggestion acceptance - Github Copilot

[SmallLemur]

When using Copilot, users would like to be able to only partially accept suggestion instead of the whole suggestion at once.
The users demand either word by word or line by line completion.

Desired behaviour:
Press a predefined key and accept the whole suggestion.
Use a predefined combination of 2 keys to accept the top line of the suggestion. (eg: For a suggestion of 3 lines, the user would need to press the combination 3 times to accept the whole suggestion). The prompt would not show the line already accepted.

[isidorn]

@SmallLemur this sounds to me like a UX problem. Is there a mock sketch for a potential solution here? Is there some other editor which already supports this?
We can also discuss it in one of our UX weekly meetings.

[SmallLemur]

@isidorn I don’t have a mock sketch. No other editors are supporting this yet but it is a requested features. I wanted to get the discussion going (doing the same for the other editors) to understand the constraints around it as well.

[hediet]

Technically, I think this would be rather easy to implement. I'd love to hear some more UX discussion before we implement this thought.
What key-binding do you have in mind?

[isidorn]

@SmallLemur do you have some UX designers on your team that would like to help here? Once we have some good ux proposal we can bring it in our UX weekly sync on Wednesday to start the discussion.

[SmallLemur]

@isidorn No I dont have a UX designer in my team. I ll see how i can come up with a suggestion and get back to you

[YitziG]

This is similar to zsh-users/zsh-autosuggestions#265. Solution for me was 'CMD + ->' to accept a word at a time.

Something similar here would be great.

[alloy]

Fish shell allows word-by-word completion using the Alt + → key-combo, which—at least on macOS—is used system-wide for navigating text word-by-word. I notice that I keep trying to automatically use this key-combo, so big +1 from me.

(This should perhaps be a feature that would need to get generic support from VS code? Did not realise this is the vscode repo.)

[isidorn]

@alloy awesome idea.
@hediet since you said this is low hanging maybe we assign to July for the initial investigation? What do you think?

[martinmr]

This would be great. I am loving copilot so far, but this is my biggest UX gripe. Copilot's first suggestions in a new piece of code tend to only be accurate for the first few words. It tends to get much better only after more context is added. Not a blocker, but it'd make it much easier to get started.

[isidorn]

We did an initial investigation and this is not low hanging as I have initially commented above. Also, this milestone we have been mostly focusing on improving the merge editor. So this one will have to continue in September.

[isidorn]

Had a sync with the VS folk and here's some very early thinking:

• When partial completion is accepted the ghost text should not change - we should use the cache. VS did multiple user studies and users always get shocked when the ghost text changes beneath them
• Undo is the user gesture to undo the last partial acceptance (this should work out of the box for us).
• Simple keybindings like word next navigation, and navigate to end of line should be used for partial word acceptance, and whole line acceptance. So same keybindnigs as cursorWordEndRight and cursorEnd commands.

Open questions (probably not for first version):

• How to make this keybindings discoverable
• Should we support the mouse? For example alt + mouse click to accept until the mouse click

[mtaran]

I've also previously advocated for a way to accept only a single line out of the multi-line completion. I would strongly support doing this at a line granularity, rather than e.g. token granularity, since I ~never run into the case where I want to accept 'more than 0 tokens but less than a line' of a multi-line completion -- it's ~always either one line or maybe a couple, or the whole completion.

Simple keybindings like word next navigation, and navigate to end of line should be used for partial word acceptance, and whole line acceptance. So same keybindnigs as cursorWordEndRight and cursorEnd commands.

Repurposing regular cursor movement commands for partial acceptance when a ghost text completion is open sounds error-prone. I see this kind of key-stealing behavior in some autocomplete systems (especially for enter), but it's always optional, since it's really easy to interfere with muscle memory and frustrate people. This would apply to text navigation commands for sure, and it would be even worse in the middle-of-the-line completion case (which would also be wonky if we want an 'accept a single token' shortcut).

[senorflor]

Hi! A use case for per-word completion: comment/natural language completion. I want this almost every time that copilot gives me a comment suggestion.

To make sure I understand the shape of the discussion, I think three issues are separable here:

1. whether to offer partial completion;
2. at what granularities (here the use case and example-based analysis is most relevant, and feed back into question 1);
3. if doing it, what default keybindings at these levels to provide so as not to hijack muscle memory (but possibly still utilize it in a parallel modifier key universe)?

Is that right, and if so at what stage does the team currently see the conversation?

For 3), in Lisp-y language tools, Paredit's keybindings might be a decent template too: in some sense what we are doing here is structurally selecting part of what is an expr -> token (falling back on a line -> token as above) structure before "acceptance" (which is already well-understood as a result of Tab by default keybinding users). That would be a more elaborate form of the partial acceptance, though, requiring a language-sensitive parse, so definitely not low hanging fruit.

[cmp-nct]

It's a marketing problem, they market the code you accept as efficiency. If they would also add the 97% of the code you have to remove carefully again it wouldn't be that a nice metric.

I believe we need to adapt the plugins on our own or write a plugin watchdog, something that monitors completions, immediately removes them and offers a word-by-word insert of the code.

[hediet]

A use case from @jrieken: He wants to accept the first couple of words here (but not the entire completion):

... Fibon|acci numbers to ensure that we get a good distribution of have a performance benchmark that

A use case for line based acceptance:

[cmp-nct]

@hediet
For jetbrains IDE's you can use my plugin (https://github.com/cmp-nct/Stewardess)
You press CTRL+ALT+D and it will complete the sentence word by word.

So in your example you press it 3 times (you'll be after "to", then you type "have a per" and you can continue with the shortcut 3 more times on the new completion text. Or just "TAB" if all is good after your intervention, it doesn't block you from using the default behavior of copilot

Though the plugin only works on IntelliJ IDE's (you need to install 'LivePlugin' and 'Stewardess')

[VictorDuranEM]

I love this suggestion. I encounter the scenario of wanting to only accept a suggestion partially a lot.

[hediet]

@VictorDuranEM would you prefer word-by-word partial acceptance or line-by-line?

[VictorDuranEM]

@VictorDuranEM would you prefer word-by-word partial acceptance or line-by-line?

It would be awesome to be able to do both, but if only one of the two is possible, then I would prefer word-by-word.

[cmp-nct]

There is no reason why only one would be doable.
A line based completion is a couple of lines of code.
Word based completion is half a page if you want to do the word separation smart, or an abstract if it's dumb.

[hediet]

First iteration has been implemented in #166956