Skip to content

lsp: Use correct LSP adapter for completion labels in remote development#50697

Merged
Veykril merged 2 commits intozed-industries:mainfrom
lingyaochu:lsp-completion
Mar 6, 2026
Merged

lsp: Use correct LSP adapter for completion labels in remote development#50697
Veykril merged 2 commits intozed-industries:mainfrom
lingyaochu:lsp-completion

Conversation

@lingyaochu
Copy link
Copy Markdown
Contributor

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_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 #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.

// 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 #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:

  • Added a solid test coverage and/or screenshots from doing manual testing
  • Done a self-review taking into account security and performance aspects
  • Aligned any UI changes with the UI checklist

Release Notes:

  • Fixed missing labels for ty completion items in remote development.

@cla-bot cla-bot bot added the cla-signed The user has signed the Contributor License Agreement label Mar 4, 2026
@github-actions github-actions bot added the community champion Issues filed by our amazing community champions! 🫶 label Mar 4, 2026
@JosephTLyons JosephTLyons requested a review from Veykril March 6, 2026 13:45
Copy link
Copy Markdown
Member

@Veykril Veykril left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@Veykril Veykril enabled auto-merge (squash) March 6, 2026 14:00
@Veykril Veykril merged commit 09b4140 into zed-industries:main Mar 6, 2026
30 checks passed
@lingyaochu lingyaochu deleted the lsp-completion branch March 6, 2026 14:18
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.
@zelenenka zelenenka added the guild Pull requests by someone in Zed Guild. NOTE: the label application is automated via github actions label Mar 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cla-signed The user has signed the Contributor License Agreement community champion Issues filed by our amazing community champions! 🫶 guild Pull requests by someone in Zed Guild. NOTE: the label application is automated via github actions

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Python ty can't show autocompletion symbol package name.

3 participants