[renkun-ken]

Member completions get short, bounded literal, type and known-field tips. The completion_label_details setting (default FALSE) shows inline signatures and tips consistently for members and ordinary symbols when supported by the editor. Selected-item details remain available in compact mode.

Bulk package signature lookup inspects stored bindings, skips active bindings and unforced promises, and reuses the signature cache. Inline mode retains the lightweight current-buffer completion path and avoids guessed annotations for conditional, future or masked declarations.

Label annotations are supplied in the initial response and preserved during resolution unless the client explicitly supports resolving labelDetails. This follows the VS Code API: its resolve capabilities cover documentation, detail and additional edits, while labels must be supplied initially. The compact default is intentional; the previous resolve-only signature annotations were not a dependable visible feature in VS Code.

Validation: relevant completion, member, resolve, scope, readiness and settings tests passed; no lint findings in changed code; git diff --check passed.

Benchmark: 20 samples per case on R 4.6.1 / macOS arm64, compared with 0720a4f. Warm lookup for 200 package signatures measured 9 → 10 ms median. Rapid-edit completion with inline details measured 74 → 31 ms in a 250-line buffer and 947.5 → 226 ms in a 10,000-line buffer. Every fixed rapid-edit request with inline details returned 200 signatures through the lightweight path. Editor rendering, IPC and debounce are excluded. See methodology and results.

[eitsupi]

ChatGPT-assisted review:

I found a few points worth addressing or clarifying.

1. Namespace access during completion

   In completion_symbol_info(), ns$get_signature() is called for each matching function candidate. Internally, PackageNamespace$get_signature() retrieves the function using get(), which may trigger active bindings.

   This also moves potentially expensive signature retrieval from selected-item resolution to completion-list generation, potentially affecting latency with up to 200 candidates.

   Could we avoid evaluating active bindings and benchmark completion latency with a large number of candidates?

2. Change in default inline signature behavior

   Previously, function signatures were added to labelDetails during resolution when the client supported them. This PR disables that behavior by default through completion_label_details = FALSE.

   Is this backward-incompatible change intentional? I agree with making additional inline value/type previews opt-in, but I'm not sure existing signature display should also be disabled.

3. Completion responsiveness

   Enabling completion_label_details disables the lightweight basic_name_completion_reply() path, potentially delaying completions until parsing finishes.

   Could we verify the latency impact, particularly during rapid typing or with larger documents?

[renkun-ken]

@eitsupi, the follow-up changes address the three review points:

1. Namespace safety: bulk completion now uses PackageNamespace$get_completion_signature(). It checks stored bindings without invoking active bindings or forcing promises, avoids namespace reloads, and reuses the existing signature cache. Regression tests cover these cases and cache invalidation after stored function changes (78d7a2f).

2. Default and VS Code behavior: keeping both member and ordinary completion lists compact by default is intentional. The old server supplied signature labelDetails during resolution, but the VS Code API contract prohibits changing labels or presentation at that stage. Its language client advertises resolve support for documentation, detail, and additionalTextEdits, not labelDetails. The old code therefore did not reliably produce visible inline signatures in VS Code. The opt-in mode now supplies annotations in the initial response. Initial labels are preserved during resolution unless the client explicitly supports resolving labelDetails; selected-item details and signature help remain available.

3. Responsiveness: inline mode now retains the lightweight current-buffer completion path. It uses available headers and conservative literal facts without waiting for the full parse, and omits guessed annotations for conditional, future, or masked declarations (d07a31a).

Compared with 0720a4f, the local median compute times were:

Workload, inline enabled	Before	After
200 package functions, cold signature cache	15 ms	15 ms
200 package functions, warm signature cache	9 ms	10 ms
Rapid edits, 250-line buffer	74 ms	31 ms
Rapid edits, 10,000-line buffer	947.5 ms	226 ms

These are 20 samples per case on R 4.6.1 / macOS arm64. Namespace preparation is outside the package-case timer; editor rendering, IPC, scheduling, and debounce are excluded. Every fixed rapid-edit request with inline details returned 200 unique candidates and 200 signatures through the lightweight path. The benchmark and full results are reproducible (88ad798).

The relevant local tests and changed-code lint pass, and all 18 CI checks passed at 88ad798.