Inline Completion provider should signal when a completion has been hidden

[marrej]

At the moment the inlineCompletionProvider signals when a completion has been shown to the user via didShow callback.

Unfortunately there is not a clear signal that a suggestion has been hidden/removed from screen (after it has been shown), that would be sent back to the provider. This makes it hard to track explicit rejections on shown suggestions. (Note that if relying only on the shown event + accepts, we might miss out on certain rejections )

Looking at the actual solution there are few easy ways how this can be achieved.

1. Respond back via the handleItemDidShow with empty insertText if there is lastCompletion, but no currentCompletion. (Although this then requires handling in the provider, to make sure that no empty suggestions are sent, otherwise this could be misleading, though there is a low likelyhood of that happening)
2. Respond back via the handleItemDidShow with undefined insertText (This would require changes in multiple places, and although it would make the behavior more understandable, I am not sure its needed)
3. Create a new handleItemDidHide callback on the provider, which could also carry additional information about why the completion was hidden (cursor move/esc/new suggestion proposed/dropdown option selected)

I am also happy to contribute any of the changes.

[hediet]

Note that if relying only on the shown event + accepts, we might miss out on certain rejections

What rejections would you miss out?

Respond back via the handleItemDidShow with empty insertText if there is lastCompletion, but no currentCompletion.

I think this would be very confusing, as we also pass in the completion item.

Create a new handleItemDidHide callback on the provider, which could also carry additional information about why the completion was hidden (cursor move/esc/new suggestion proposed/dropdown option selected)

Understanding the reason why a completion was hidden might be useful.

@isidorn do you know if Copilot had similar asks?

[marrej]

What rejections would you miss out?

We are relying on some additional heuristics (e.g. waiting for a short time so the user has time to react after a completion has rendered) to account for all usable completions as the didShow might have also been a flicker between 2 different suggestions. The Rejection for us, is basically not accepted usable completion.

Reason why we would miss out: At the moment the didShow will fire when there is a new completion, as well as if the completions change. But it does not signal when a completion has been hidden (e.g. by pressing Esc/changing the CompletionItem in dropdown/not having any more a suggestion provided), so in this case we would incorrectly account for the completion as usable (e.g. we would have to calculate the time to be able to react only between two Completions, which might be wrong in cases when - completion is provided, then hidden, then a new one is provided).

We could potentially calculate it via the items that we provide to the CompletionProvider, but that wouldn't be fully correct, as we can provide multiple items, which do not have to be shown.

Understanding the reason why a completion was hidden might be useful.

+1, that would be very helpful for us and a preferred way, although I understand that it might change multiple places throughout the Stack.

[hsenag]

@isidorn do you know if Copilot had similar asks?

I think this would be useful for Copilot, though I haven't thought about it in detail. The new callback seems best for migration.

[marrej]

@hediet I see that there has been rejection added to the inlineCompletion handlers, can we try to bind it to the Show listeners so we can signal to the extensions that the state of a completion has changed? #242284

It would be also helpful if we can add the rejection to the extension as this binding does not currently exist #241328 (This would require updates after the first proposed PR, but didn't want to mash them together)

[hediet]

Inline Completion provider should signal when a completion has been hidden

handleEndOfLifetime should solve this. There is also a details object, which indicates why its lifetime ended.