bQUARKz
6e594c15d7
All checks were successful
JaCoCo Coverage #### Project Overview
No changes detected, that affect the code coverage.
* Line Coverage: 61.37% (17351/28272)
* Branch Coverage: 52.31% (6722/12850)
* Lines of Code: 28272
* Cyclomatic Complexity: 11325
#### Quality Gates Summary
Output truncated.
Test / Build skipped: 15, passed: 601
Intrepid/Prometeu/Studio/pipeline/head This commit looks good
63 lines
2.1 KiB
Markdown
63 lines
2.1 KiB
Markdown
---
|
|
id: AGD-0052
|
|
ticket: pbs-lsp-completion-depth
|
|
title: PBS LSP Completion Depth
|
|
status: open
|
|
created: 2026-07-15
|
|
resolved:
|
|
decision:
|
|
tags: [studio, lsp, vscode, compiler-pbs, editor, completion]
|
|
---
|
|
|
|
## Pain
|
|
|
|
Domain owner: `studio/lsp`
|
|
|
|
PBS completion works for core cases, but a complete daily-use experience needs ranking, resolve details, snippets, overload handling, context-aware suggestions, and richer documentation.
|
|
|
|
## Context
|
|
|
|
The current LSP announces completion with trigger character '.' and returns detail/documentation for resolved compiler candidates. It does not use resolveProvider, snippets, broad trigger contexts, or advanced ranking.
|
|
|
|
## Open Questions
|
|
|
|
- [ ] Which completion contexts should be supported first beyond member access?
|
|
- [ ] Should completion use resolveProvider for expensive documentation/details or return everything eagerly?
|
|
- [ ] How should overloads, snippets, imports, keywords, and stdlib candidates be ranked?
|
|
|
|
## Options
|
|
|
|
### Option A - Eager rich completion
|
|
|
|
- **Approach:** Return labels, details, docs, and snippets directly in every completion response.
|
|
- **Pro:** Simple client behavior and immediate docs.
|
|
- **Con:** Can become expensive for broad/global completion.
|
|
- **Maintainability:** Good while candidate sets remain small.
|
|
|
|
### Option B - Completion resolve provider
|
|
|
|
- **Approach:** Return lightweight candidates first and populate expensive docs/details through `completionItem/resolve`.
|
|
- **Pro:** Scales better for large candidate sets and import-aware suggestions.
|
|
- **Con:** Requires client/server resolve plumbing and stable candidate identities.
|
|
- **Maintainability:** Strong for a full LSP.
|
|
|
|
## Tradeoffs
|
|
|
|
The current eager model is fine for scoped completions, but global/import-aware completion may need resolve to avoid latency.
|
|
|
|
## Recommendation
|
|
|
|
Prefer a staged approach: keep eager for current contexts, design resolve before broad workspace/import completion.
|
|
|
|
## Discussion
|
|
|
|
Define completion contexts and ranking before adding snippets or resolve.
|
|
|
|
## Resolution
|
|
|
|
Ainda em aberto.
|
|
|
|
## Next Step
|
|
|
|
List first-wave completion contexts beyond member access.
|