# Signal rejection on inline completion drop

[marrej]

Problem statement

With the current inline completion, we are aware only of completions being accepted and made visible. With the introduction of the rejection handler we are aware also of explicit rejection. What is still missing though is understanding when a completion has been discarded by natural means, such as changing a character (without having completion reretrieved), or typing through without having extensions recalculate possible visibility of a completion (Which can also reduce load on the client, assuming that there can be multiple extensions set up which consume & provide completions).

Proposal

Extend the rejection handler to provide the Explicit/Implicit signal (can be made more elaborate in to a enum if neccessary to signal different kind of rejections, such as type through/location change.... but that doesn't seem to be that neccessary), and allow the Show handler to also signal rejection when a No successive completion is to be shown.

As a continuation it would be great if the rejection signals flowed in to the extension #241328

Closes #192546