Investigate resolving and inserting additional text edits async

[jrieken]

This is somewhat the opposite of #87187 and the acknowledgement that computing additional text edits for all items upfront is too demanding. This issue is only about additionalTextEdits and the goal is a pragmatic solution, similar to the one that we have for format on type. 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

[jrieken]

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 Follow-up with completion item changes during resolve #87187
• Hitting enter on suggestion doesn't import module #73311 - TS issue for having incomplete items
• CompletionItemProvider#resolveCompletionItem must not change insert behaviour Dart-Code/Dart-Code#2290
• java for returning very few (resolved) completions, e.g doing the right thing

[jrieken]

/cc @jdneo - 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)?

[jdneo]

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?

Yes.

Could Java return results faster when additional text edits are computed during resolve (and therefore only for selected items)?

I think so!

@Eskibear is the dev who was working on Java completion. I believe he can provide more insights toward this topic.

// cc @akaroml @testforstephen @fbricon

[fbricon]

@jrieken this is exactly the behavior that jdt.ls 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 it was not spec'ed that way 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.

[fbricon]

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.