2.1 KiB
| id | ticket | title | status | created | resolved | decision | tags | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| AGD-0045 | pbs-lsp-workspace-symbols | PBS LSP Workspace Symbols | open | 2026-07-15 |
|
Pain
Domain owner: studio/lsp
VS Code cannot search PBS symbols across the workspace, so users cannot quickly jump to functions, services, structs, constants, or stdlib-exposed APIs by name.
Context
Document-level editorial features exist, but the LSP does not announce workspaceSymbolProvider and the compiler pipeline does not expose a project-wide symbol index designed for editor queries.
Open Questions
- Should workspace symbols include only project files or also imported stdlib and SDK surfaces?
- What symbol kinds and ranking should be returned for duplicate names or overloads?
- Should the symbol index be cached from analysis snapshots or rebuilt per request in the first implementation?
Options
Option A - Project source index only
- Approach: Index project-owned declarations from analysis snapshots and expose
workspace/symbol. - Pro: Clear ownership and physical locations.
- Con: Does not help users discover stdlib/SDK symbols.
- Maintainability: Strong as a first wave.
Option B - Project plus stdlib index
- Approach: Include project declarations and imported stdlib/SDK surfaces in the workspace symbol result set.
- Pro: Better discovery, especially for new users.
- Con: Requires a navigation policy for stdlib source or virtual targets.
- Maintainability: Good if stdlib target handling is solved; awkward otherwise.
Tradeoffs
Workspace symbols are partly navigation and partly discovery. Including stdlib too early can create broken jumps if target locations are not defined.
Recommendation
Prefer Option A first, then add stdlib once definition has a target policy.
Discussion
This should follow document symbols and the semantic location/index work.
Resolution
Ainda em aberto.
Next Step
Decide whether first-wave workspace search includes stdlib or project-only symbols.