2.1 KiB
| id | ticket | title | status | created | resolved | decision | tags | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| AGD-0053 | pbs-lsp-folding-and-selection-ranges | PBS LSP Folding and Selection Ranges | open | 2026-07-15 |
|
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.