Code change:
} else { // exec command, done <del> this._commandService.executeCommand(item.completion.command.id, ...(item.completion.command.arguments ? [...item.completion.command.arguments] : [])) .catch(onUnexpectedError) .finally(() => this.model.clear()); // <- clear only now, keep commands alive </del> <ins> tasks.push(this._commandService.executeCommand(item.completion.command.id, ...(item.completion.command.arguments ? [...item.completion.command.arguments] : [])).catch(onUnexpectedError)); </ins> this.model.cancel(); } if (flags & InsertFlags.KeepAlternativeSuggestions) { this._alternatives.value.set(event, next => { <ins> // cancel resolving of additional edits cts.cancel(); </ins> // this is not so pretty. when inserting the 'next' // suggestion we undo until we are at the state at // which we were before inserting the previous suggestion...

Related discussion:
text: This is somewhat the opposite of and the acknowledgement that computing additional text edits for all items upfront is too demanding. This issue is only about and the goal is a pragmatic solution, similar to the one that we have for . Idea accept an unresolved completion proceed with insertion as usual set up a content change listener resolve the items once resolved check if additional edits overlap with "concurrent" changes. when they overlap, do nothing otherwise proceed
The first version for this is now merged to master, it's a pragmatic approach that's better then not resolving but worst than (costly) upfront resolving. Items to followup on [ ] telemetry and follow up issues [ ] - TS issue for having incomplete items [ ] [ ] java for returning very few (resolved) completions, e.g doing the right thing
/cc - My understanding is that Java resolves all items upfront, e.g compute additional text edits during "provide", and that it is quite expensive and therefore Java only returns a small amount of items. Is that correct? Could Java return results faster when additional text edits are computed during resolve (and therefore only for selected items)?
Yes. I think so! is the dev who was working on Java completion. I believe he can provide more insights toward this topic. // cc
this is exactly the behavior that used to have, ie compute all the completion items first (fast), then the text edits were computed during resolveCompletion. We were asked to not do that as and changed to return a small subset of completion items (with incomplete=true), with full text edits computed upfront. The user experience is definitely not as good as with our initial implementation.
To be clear, computing any Java textedit upfront is costly when returning 100+ items (and we can return several thousands items). We'd prefer if the async insertion of textedits covered all textedits, not just the additional ones.
The requirements discussed in are still true and there are no plans to change that. There is (which might be derived from ) and . The former () is inserted at the cursor and must be inserted synchronous to accepting a completion (we cannot block typing while waiting for that). The latter () is meant for things like import-statements and we now want to relax that, e.g it can come late and we try to apply those edits despite the user having typed more.