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-0053
|
|
ticket: pbs-lsp-folding-and-selection-ranges
|
|
title: PBS LSP Folding and Selection Ranges
|
|
status: open
|
|
created: 2026-07-15
|
|
resolved:
|
|
decision:
|
|
tags: [studio, lsp, vscode, compiler-pbs, editor, folding, selection-range]
|
|
---
|
|
|
|
## Pain
|
|
|
|
Domain owner: `studio/lsp`
|
|
|
|
PBS users do not get structural folding or smart selection ranges, so navigating and selecting nested functions, blocks, services, attributes, and Doc text blocks is more manual than it should be.
|
|
|
|
## Context
|
|
|
|
The parser knows syntactic spans for declarations and blocks. The LSP currently does not announce foldingRangeProvider or selectionRangeProvider.
|
|
|
|
## Open Questions
|
|
|
|
- [ ] Should folding ranges be computed from AST spans, token pairs, or a hybrid that handles malformed files?
|
|
- [ ] Which constructs should fold in the first wave: imports, declarations, blocks, attributes, text blocks, or all of them?
|
|
- [ ] What selection range hierarchy should VS Code expose for identifiers, calls, params, blocks, and declarations?
|
|
|
|
## Options
|
|
|
|
### Option A - Parser span ranges
|
|
|
|
- **Approach:** Use AST spans for declarations, blocks, parameter lists, and text blocks.
|
|
- **Pro:** Accurate for well-formed code and easy to map to LSP ranges.
|
|
- **Con:** Can degrade when parsing fails mid-file.
|
|
- **Maintainability:** Good because parser owns structure.
|
|
|
|
### Option B - Token pair scanning
|
|
|
|
- **Approach:** Compute ranges from brace/paren/text-block tokens without relying on full AST validity.
|
|
- **Pro:** More resilient during malformed edits.
|
|
- **Con:** Less semantically meaningful and can produce noisy ranges.
|
|
- **Maintainability:** Good only as fallback.
|
|
|
|
## Tradeoffs
|
|
|
|
Folding and selection should keep working while typing. AST ranges are higher quality, but token fallback may be needed for broken files.
|
|
|
|
## Recommendation
|
|
|
|
Prefer a hybrid: AST ranges first, token fallback for unmatched/incomplete constructs.
|
|
|
|
## Discussion
|
|
|
|
This is an editor UX feature with low semantic dependency and can be planned independently.
|
|
|
|
## Resolution
|
|
|
|
Ainda em aberto.
|
|
|
|
## Next Step
|
|
|
|
Decide first-wave foldable constructs and selection hierarchy.
|