lsp: Add container_name to lsp::Symbol#46822
Merged
MrSubidubi merged 5 commits intozed-industries:mainfrom Feb 4, 2026
Merged
Conversation
df865da to
7982c36
Compare
MrSubidubi
requested changes
Jan 19, 2026
Member
MrSubidubi
left a comment
There was a problem hiding this comment.
Thanks for this!
If we want to add this, you'll need to follow the changes as outlined in #46269 that does something similar. We cannot change the old WIT definitions. Existing extensions will break with your current set of changes, so we need to update this for v0.8.0 and keep the previous versions as is.
7982c36 to
49fc6bb
Compare
Contributor
Author
|
Thanks! Updated to follow the #46269 pattern and |
49fc6bb to
88a1d8f
Compare
Contributor
Author
|
Friendly ping. I believe I addressed the requested changes, but please let me know if any other changes are needed. |
ce4f491 to
93e63cd
Compare
Member
|
Will try taking a look soonish, sorry for the delay! |
Some language servers include local symbols (e.g., local variables, parameters) in workspace symbol results. Without the container_name field, these symbols lack context information, making it difficult to distinguish them from top-level definitions and hindering efficient symbol lookup. This change exposes the `container_name` field from LSP SymbolInformation to the extension API, allowing language server extensions to access `symbol.container_name` in `label_for_symbol` and provide meaningful context when rendering symbol labels. The container_name field is only added to the v0.8.0 extension API. Older API versions use conversion functions that drop this field, maintaining backward compatibility with existing extensions. Release Notes: - Added `container_name` field to `lsp::Symbol`, accessible via the extension API's `label_for_symbol` function
93e63cd to
0c7a6f0
Compare
rtfeldman
pushed a commit
that referenced
this pull request
Feb 5, 2026
Some language servers include local symbols (e.g., local variables, parameters) in workspace symbol results. Without the `containerName` information, these symbols lack context information, making it difficult to distinguish them from top-level definitions and hindering efficient symbol lookup. This change exposes the `container_name` field from LSP [`SymbolInformation`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#symbolInformation) to the extension API, allowing language server extensions to access `symbol.container_name` in `label_for_symbol` and provide meaningful context when rendering symbol labels. Note: The `container_name `field is added to all extension API versions because they seem to share the same underlying Rust types via wasmtime bindgen. The field is optional, so existing extensions would remain compatible as far as I understand. Closes #ISSUE Release Notes: - Added `container_name` field to `lsp::Symbol`, accessible via the extension API's `label_for_symbol` function --------- Co-authored-by: MrSubidubi <finn@zed.dev>
naaiyy
added a commit
to Glass-HQ/Glass
that referenced
this pull request
Feb 16, 2026
Key changes: - Semantic highlighting support (zed-industries#46356) - major new editor feature - Edit predictions via Ollama (zed-industries#48233) - local AI edit predictions - Side-by-side diff: staging/unstaging/restoring on LHS, hunk controls, gutter highlights - Branch diff fix when committing/changing branches (zed-industries#48388) - Settings UI: AI tool permissions page (zed-industries#48277) - Version bump to v0.224 (kept our v0.0.1) - Close toasts on middle mouse click (zed-industries#48208) - DAP settings made optional (zed-industries#43647) - REPL quality of life improvements (zed-industries#47533) - Mercury accept/reject tracking (zed-industries#48306) - Toolbar menu and EP menu telemetry (zed-industries#48225, zed-industries#48229) - lsp::Symbol now includes container_name (zed-industries#46822) - Nushell/Elvish/Rc always_allow patterns (zed-industries#48395) - Agent terminal security rules expanded (zed-industries#48399) Conflict resolution: - collab/rpc.rs, collab_ui, collab editor_tests: deleted (collab removed) - vim (yank, replace, test): deleted (vim removed) - util/shell.rs: deleted (extracted to Obsydian-HQ/gpui) - GPUI (app.rs, windows/platform.rs, platform_scheduler.rs): deleted (Obsydian) - editor/items.rs: merged imports (added ExcerptId, ExcerptRange, kept SearchWithinRange) - lsp_store.rs: added SemanticTokensData import, removed GlobalLogStore/LanguageServerKind - proto.rs: added SemanticTokens to entity_messages, removed JoinProject/LeaveProject - lsp_button.rs: kept empty server UI, added is_via_ssh check from upstream - edit_prediction_button.rs: kept TitleBarItemView import - vscode_import.rs: added semantic_token_rules, removed helix_mode (not in our struct) - zed/Cargo.toml: kept v0.0.1 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Some language servers include local symbols (e.g., local variables, parameters) in workspace symbol results. Without the
containerNameinformation, these symbols lack context information, making it difficult to distinguish them from top-level definitions and hindering efficient symbol lookup.This change exposes the
container_namefield from LSPSymbolInformationto the extension API, allowing language server extensions to accesssymbol.container_nameinlabel_for_symboland provide meaningful context when rendering symbol labels.Note: The
container_namefield is added to all extension API versions because they seem to share the same underlying Rust types via wasmtime bindgen. The field is optional, so existing extensions would remain compatible as far as I understand.Closes #ISSUE
Release Notes:
container_namefield tolsp::Symbol, accessible via the extension API'slabel_for_symbolfunction