lsp: Use correct LSP adapter for completion labels in remote development#50697
Merged
Veykril merged 2 commits intozed-industries:mainfrom Mar 6, 2026
Merged
lsp: Use correct LSP adapter for completion labels in remote development#50697Veykril merged 2 commits intozed-industries:mainfrom
Veykril merged 2 commits intozed-industries:mainfrom
Conversation
dapovoa
pushed a commit
to dapovoa/zed
that referenced
this pull request
Mar 7, 2026
…ent (zed-industries#50697) Closes zed-industries#47917 Currently, during remote development, Zed uses the first available local LSP adapter to handle all label computing. This isn't ideal and causes bugs because different adapters may expect different label formats. By leveraging the `all_capable_for_proto_request` method, we can now retrieve the specific language server name and use it as a key to find the correct LSP adapter for label population. Even if this lookup fails, we can still fall back to the first adapter, so this PR should provide more accurate label population than before. This addresses the root cause of zed-industries#47917, which stems from two main issues. For example, in remote Python development, the `basedpyright` adapter might incorrectly handle labels even when the remote server is actually `ty`. The completion items returned by `ty` are slightly different from `basedpyright`: `ty` stores labels in `labelDetails.detail`, while basedpyright uses `labelDetails.description`. By matching the correct adapter, we ensure labels are populated properly for completion items. ```json // RPC message returned by `ty`, label is in `labelDetails.detail` { ... "labelDetails": { "detail": " (import pathlib)" }, ... } // RPC message returned by `basedpyright`, label is in `labelDetails.description` { ... "labelDetails": { "description": "pathlib" }, ... } ``` Additionally, adapters registered via `register_available_lsp_adapter` are lazy-loaded into the `LanguageRegistry` (which is the case for `ty` before). In remote scenarios, the adapter might be loaded on the remote server but not on the local host, making it hard to find in `lsp_adapters`. This is partially resolved in zed-industries#50662, and combined with this PR, we can fully address zed-industries#47917. There is still more to do, however. In some cases, we still can't find the correct local LSP adapter if the local host lacks the registry that the remote server has; this typically happens when the adapter is registered via `register_available_lsp_adapter`. I've opened a feature discussion zed-industries#49178 to track this. If it's decided that this needs further refinement, I'm happy to continue working on it. Before you mark this PR as ready for review, make sure that you have: - [ ] Added a solid test coverage and/or screenshots from doing manual testing - [x] Done a self-review taking into account security and performance aspects - [x] Aligned any UI changes with the [UI checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) Release Notes: - Fixed missing labels for `ty` completion items in remote development.
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
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.
Closes #47917
Currently, during remote development, Zed uses the first available local LSP adapter to handle all label computing. This isn't ideal and causes bugs because different adapters may expect different label formats. By leveraging the
all_capable_for_proto_requestmethod, we can now retrieve the specific language server name and use it as a key to find the correct LSP adapter for label population. Even if this lookup fails, we can still fall back to the first adapter, so this PR should provide more accurate label population than before.This addresses the root cause of #47917, which stems from two main issues. For example, in remote Python development, the
basedpyrightadapter might incorrectly handle labels even when the remote server is actuallyty. The completion items returned bytyare slightly different frombasedpyright:tystores labels inlabelDetails.detail, while basedpyright useslabelDetails.description. By matching the correct adapter, we ensure labels are populated properly for completion items.Additionally, adapters registered via
register_available_lsp_adapterare lazy-loaded into theLanguageRegistry(which is the case fortybefore). In remote scenarios, the adapter might be loaded on the remote server but not on the local host, making it hard to find inlsp_adapters. This is partially resolved in #50662, and combined with this PR, we can fully address #47917.There is still more to do, however. In some cases, we still can't find the correct local LSP adapter if the local host lacks the registry that the remote server has; this typically happens when the adapter is registered via
register_available_lsp_adapter. I've opened a feature discussion #49178 to track this. If it's decided that this needs further refinement, I'm happy to continue working on it.Before you mark this PR as ready for review, make sure that you have:
Release Notes:
tycompletion items in remote development.