Restore single-proposal insertion in async content assist
Aligned the fast async content-assist path with the established slow path so manually requested single proposals are inserted automatically again.
Editor UX correctness
Eclipse async content assist once again inserts a single proposal immediately during manual invocation, independent of proposal-computation timing.
Problem
The fast path inserted a sole completion proposal only when completion-on-type was enabled. Java editor users could therefore receive a one-item popup instead of immediate insertion, while the slower asynchronous path behaved correctly, making the result dependent on computation timing.
Approach
Removes the unrelated completion-on-type condition while retaining the manual-invocation guard, deletes the now-unused accessor, and adds coverage for manual invocation, prefix completion, multiple proposals, auto activation, and completion-on-type.
Impact and scope
- Restores the expected one-keystroke content-assist flow for single proposals such as the Java sysout template.
- Eliminates timing-dependent behavior by making fast and delayed asynchronous proposal paths follow the same insertion rule.
- Preserves auto-activation behavior through the existing manual-invocation guard instead of broadening automatic insertion.
- Adds a focused regression matrix around the interaction modes most likely to be affected; the related cross-repository JDT issue remained open when verified.
Validation
- Verified the reported Java editor behavior before and after the change: a one-item popup became direct System.out.println insertion.
- All 18 hosted checks passed across Linux, Windows, macOS, CodeQL, API tooling, compiler, and test jobs.
- The change received contributor approval before merge, and the functional commit is authored by Goutam Adwant.