Support code lens in the editor by SomeoneToIgnore · Pull Request #54100 · zed-industries/zed

SomeoneToIgnore · 2026-04-16T17:13:24Z

Adds the editor: toggle code lens action and the "code_lens" settings (disabled by default) which, when enabled, will make Zed to query the language server for code lens.

A language server might need more configuration (Zed has "lsp" settings section for this) first to start sending meaningful code lens responses back.

lens.mov

Release Notes:

Added LSP code lens support, disabled by default, use "code_lens": "on" settings to enable or the action to toggle them on

Co-authored-by: Lukas Wirth <me@lukaswirth.dev>

mustakimali · 2026-04-23T10:07:52Z

Thanks 👏🏽 - can't wait for the release.

…s#54664) Follow-up to zed-industries#54100 Release Notes: - N/A

Follow-up to zed-industries#54100 Instead of relying on "line number" that could have overlapped depending on the range we query, use hierarchical IDset: `block id -> lens #` to ensure no clashes happen anymore. Release Notes: - N/A

Follow-up to zed-industries#54100 Closes zed-industries#55046 Before: https://github.com/user-attachments/assets/d4730342-3526-48a8-8050-b398725a2cb9 After: https://github.com/user-attachments/assets/5493a0a1-3a8e-4215-a10c-8cd9bb04141d Release Notes: - Fixed code lens flickering when typing

…ed lens (#57790) Follow-up to #54100 LSP [code lens](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#codeLens) has the only textual data in [`command`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#command), which we use for rendering (`command.title`). Certain language servers do not send the command by default until resolved, and this is the only field worth resolving in the code lens which we have to fetch asynchronously as the user types. Not including such lens at all caused flickering and #55075 had dealt with this by reserving the block for all code lens and swapping them with the resolved data later. Yet, certain language servers return empty commands even after resolving, to indicate "nothing referencing this", as it is shown in VSCode: <img width="951" height="424" alt="image" src="https://github.com/user-attachments/assets/19c8db24-c312-4c33-9da3-003da11e27a3" /> Before, we have removed blocks for such lens with no command after the resolve, but this caused flickering as reported in #55075 (comment) Thus, this PR falls back to the placeholder for such lens, to avoid any flickering and odd empty blocks. Also, this PR reworks the tests to have the assertions more readable. Before: https://github.com/user-attachments/assets/6af50fc5-92fb-4ce0-b07b-b2867be75c02 After: https://github.com/user-attachments/assets/4aa91c12-ae3c-4fb8-9bbd-a61d6edb79df Release Notes: - Fixed code lens flickering when resolved to no commands

…ed lens (#57790) (cherry-pick to preview) (#57797) Cherry-pick of #57790 to preview ---- Follow-up to #54100 LSP [code lens](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#codeLens) has the only textual data in [`command`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#command), which we use for rendering (`command.title`). Certain language servers do not send the command by default until resolved, and this is the only field worth resolving in the code lens which we have to fetch asynchronously as the user types. Not including such lens at all caused flickering and #55075 had dealt with this by reserving the block for all code lens and swapping them with the resolved data later. Yet, certain language servers return empty commands even after resolving, to indicate "nothing referencing this", as it is shown in VSCode: <img width="951" height="424" alt="image" src="https://github.com/user-attachments/assets/19c8db24-c312-4c33-9da3-003da11e27a3" /> Before, we have removed blocks for such lens with no command after the resolve, but this caused flickering as reported in #55075 (comment) Thus, this PR falls back to the placeholder for such lens, to avoid any flickering and odd empty blocks. Also, this PR reworks the tests to have the assertions more readable. Before: https://github.com/user-attachments/assets/6af50fc5-92fb-4ce0-b07b-b2867be75c02 After: https://github.com/user-attachments/assets/4aa91c12-ae3c-4fb8-9bbd-a61d6edb79df Release Notes: - Fixed code lens flickering when resolved to no commands Co-authored-by: Kirill Bulatov <kirill@zed.dev>

…ed lens (#57790) (cherry-pick to stable) (#57796) Cherry-pick of #57790 to stable ---- Follow-up to #54100 LSP [code lens](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#codeLens) has the only textual data in [`command`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#command), which we use for rendering (`command.title`). Certain language servers do not send the command by default until resolved, and this is the only field worth resolving in the code lens which we have to fetch asynchronously as the user types. Not including such lens at all caused flickering and #55075 had dealt with this by reserving the block for all code lens and swapping them with the resolved data later. Yet, certain language servers return empty commands even after resolving, to indicate "nothing referencing this", as it is shown in VSCode: <img width="951" height="424" alt="image" src="https://github.com/user-attachments/assets/19c8db24-c312-4c33-9da3-003da11e27a3" /> Before, we have removed blocks for such lens with no command after the resolve, but this caused flickering as reported in #55075 (comment) Thus, this PR falls back to the placeholder for such lens, to avoid any flickering and odd empty blocks. Also, this PR reworks the tests to have the assertions more readable. Before: https://github.com/user-attachments/assets/6af50fc5-92fb-4ce0-b07b-b2867be75c02 After: https://github.com/user-attachments/assets/4aa91c12-ae3c-4fb8-9bbd-a61d6edb79df Release Notes: - Fixed code lens flickering when resolved to no commands Co-authored-by: Kirill Bulatov <kirill@zed.dev>

Follow-up to zed-industries/zed#54100 Release Notes: - N/A

Follow-up to zed-industries/zed#54100 Instead of relying on "line number" that could have overlapped depending on the range we query, use hierarchical IDset: `block id -> lens #` to ensure no clashes happen anymore. Release Notes: - N/A

Follow-up to zed-industries/zed#54100 Closes zed-industries/zed#55046 Before: https://github.com/user-attachments/assets/d4730342-3526-48a8-8050-b398725a2cb9 After: https://github.com/user-attachments/assets/5493a0a1-3a8e-4215-a10c-8cd9bb04141d Release Notes: - Fixed code lens flickering when typing

Based on zed-industries/zed#54100 (comment) * Adjusts the code lens display closer to what VSCode does: have blank placeholders for the code lens need resolving. Zed will remove them if resolve returns nothing, so some small amount of jitter is still there. * Also reworks LspStore layer to provide a simple resolve method, without any ranges involved, grouping that logic in the editor itself. This allows to process each resolve request separately, updating editor blocks as soon as possible. Before: https://github.com/user-attachments/assets/d6759a90-0087-4658-abf8-8e2767bc63a2 After: https://github.com/user-attachments/assets/cb8f976c-b3fc-4f66-bb9f-812108255c90 Release Notes: - Fixed resolved lens causing flickers

…ed lens (#57790) Follow-up to zed-industries/zed#54100 LSP [code lens](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#codeLens) has the only textual data in [`command`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#command), which we use for rendering (`command.title`). Certain language servers do not send the command by default until resolved, and this is the only field worth resolving in the code lens which we have to fetch asynchronously as the user types. Not including such lens at all caused flickering and zed-industries/zed#55075 had dealt with this by reserving the block for all code lens and swapping them with the resolved data later. Yet, certain language servers return empty commands even after resolving, to indicate "nothing referencing this", as it is shown in VSCode: <img width="951" height="424" alt="image" src="https://github.com/user-attachments/assets/19c8db24-c312-4c33-9da3-003da11e27a3" /> Before, we have removed blocks for such lens with no command after the resolve, but this caused flickering as reported in zed-industries/zed#55075 (comment) Thus, this PR falls back to the placeholder for such lens, to avoid any flickering and odd empty blocks. Also, this PR reworks the tests to have the assertions more readable. Before: https://github.com/user-attachments/assets/6af50fc5-92fb-4ce0-b07b-b2867be75c02 After: https://github.com/user-attachments/assets/4aa91c12-ae3c-4fb8-9bbd-a61d6edb79df Release Notes: - Fixed code lens flickering when resolved to no commands

…ed lens (zed-industries#57790) Follow-up to zed-industries#54100 LSP [code lens](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#codeLens) has the only textual data in [`command`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#command), which we use for rendering (`command.title`). Certain language servers do not send the command by default until resolved, and this is the only field worth resolving in the code lens which we have to fetch asynchronously as the user types. Not including such lens at all caused flickering and zed-industries#55075 had dealt with this by reserving the block for all code lens and swapping them with the resolved data later. Yet, certain language servers return empty commands even after resolving, to indicate "nothing referencing this", as it is shown in VSCode: <img width="951" height="424" alt="image" src="https://github.com/user-attachments/assets/19c8db24-c312-4c33-9da3-003da11e27a3" /> Before, we have removed blocks for such lens with no command after the resolve, but this caused flickering as reported in zed-industries#55075 (comment) Thus, this PR falls back to the placeholder for such lens, to avoid any flickering and odd empty blocks. Also, this PR reworks the tests to have the assertions more readable. Before: https://github.com/user-attachments/assets/6af50fc5-92fb-4ce0-b07b-b2867be75c02 After: https://github.com/user-attachments/assets/4aa91c12-ae3c-4fb8-9bbd-a61d6edb79df Release Notes: - Fixed code lens flickering when resolved to no commands

Follow-up to zed-industries#54100 Closes zed-industries#58864 Release Notes: - Fixed code lens not being refresh after the corresponding capability was dynamically registered --------- Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>

…59999) Follow-up to zed-industries#54100 Closes zed-industries#59122 Original PR overlooked that the resolve was not handled from the remote hosts at all... Also, fixes the re-fetch of code lens not taking new language servers into account: before, it exit early whilst now it actually re-fetches the lens for the new servers. Before: <img width="1728" height="1084" alt="before" src="https://github.com/user-attachments/assets/9ee8205b-084b-4409-9abc-18c4ddb9c4e9" /> After: <img width="1728" height="1084" alt="after" src="https://github.com/user-attachments/assets/16ad76dc-25e1-4257-80dc-b5aeabc9a4ef" /> Release Notes: - Fixed code lens not being resolved in remote workflows

…s#54664) Follow-up to zed-industries#54100 Release Notes: - N/A

Follow-up to zed-industries#54100 Instead of relying on "line number" that could have overlapped depending on the range we query, use hierarchical IDset: `block id -> lens #` to ensure no clashes happen anymore. Release Notes: - N/A

Follow-up to zed-industries#54100 Closes zed-industries#55046 Before: https://github.com/user-attachments/assets/d4730342-3526-48a8-8050-b398725a2cb9 After: https://github.com/user-attachments/assets/5493a0a1-3a8e-4215-a10c-8cd9bb04141d Release Notes: - Fixed code lens flickering when typing

Based on zed-industries#54100 (comment) * Adjusts the code lens display closer to what VSCode does: have blank placeholders for the code lens need resolving. Zed will remove them if resolve returns nothing, so some small amount of jitter is still there. * Also reworks LspStore layer to provide a simple resolve method, without any ranges involved, grouping that logic in the editor itself. This allows to process each resolve request separately, updating editor blocks as soon as possible. Before: https://github.com/user-attachments/assets/d6759a90-0087-4658-abf8-8e2767bc63a2 After: https://github.com/user-attachments/assets/cb8f976c-b3fc-4f66-bb9f-812108255c90 Release Notes: - Fixed resolved lens causing flickers

…ed lens (zed-industries#57790) Follow-up to zed-industries#54100 LSP [code lens](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#codeLens) has the only textual data in [`command`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#command), which we use for rendering (`command.title`). Certain language servers do not send the command by default until resolved, and this is the only field worth resolving in the code lens which we have to fetch asynchronously as the user types. Not including such lens at all caused flickering and zed-industries#55075 had dealt with this by reserving the block for all code lens and swapping them with the resolved data later. Yet, certain language servers return empty commands even after resolving, to indicate "nothing referencing this", as it is shown in VSCode: <img width="951" height="424" alt="image" src="https://github.com/user-attachments/assets/19c8db24-c312-4c33-9da3-003da11e27a3" /> Before, we have removed blocks for such lens with no command after the resolve, but this caused flickering as reported in zed-industries#55075 (comment) Thus, this PR falls back to the placeholder for such lens, to avoid any flickering and odd empty blocks. Also, this PR reworks the tests to have the assertions more readable. Before: https://github.com/user-attachments/assets/6af50fc5-92fb-4ce0-b07b-b2867be75c02 After: https://github.com/user-attachments/assets/4aa91c12-ae3c-4fb8-9bbd-a61d6edb79df Release Notes: - Fixed code lens flickering when resolved to no commands

Follow-up to zed-industries#54100 Closes zed-industries#58864 Release Notes: - Fixed code lens not being refresh after the corresponding capability was dynamically registered --------- Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>

…59999) Follow-up to zed-industries#54100 Closes zed-industries#59122 Original PR overlooked that the resolve was not handled from the remote hosts at all... Also, fixes the re-fetch of code lens not taking new language servers into account: before, it exit early whilst now it actually re-fetches the lens for the new servers. Before: <img width="1728" height="1084" alt="before" src="https://github.com/user-attachments/assets/9ee8205b-084b-4409-9abc-18c4ddb9c4e9" /> After: <img width="1728" height="1084" alt="after" src="https://github.com/user-attachments/assets/16ad76dc-25e1-4257-80dc-b5aeabc9a4ef" /> Release Notes: - Fixed code lens not being resolved in remote workflows

SomeoneToIgnore requested review from Veykril and osiewicz April 16, 2026 17:13

SomeoneToIgnore assigned Veykril and osiewicz Apr 16, 2026

cla-bot Bot added the cla-signed The user has signed the Contributor License Agreement label Apr 16, 2026

zed-community-bot Bot added the staff Pull requests authored by a current member of Zed staff label Apr 16, 2026

SomeoneToIgnore force-pushed the kb/code-lens branch 8 times, most recently from ffdc2d6 to d2d2f4d Compare April 17, 2026 09:51

aviatesk mentioned this pull request Apr 17, 2026

lsp: Resolve code lenses before surfacing them as code actions #54175

Closed

5 tasks

SomeoneToIgnore force-pushed the kb/code-lens branch 4 times, most recently from 69e9f35 to 433c5f4 Compare April 19, 2026 20:41

Support code lens in the editor

edf2fa6

SomeoneToIgnore force-pushed the kb/code-lens branch from 433c5f4 to edf2fa6 Compare April 19, 2026 20:42

Veykril reviewed Apr 20, 2026

View reviewed changes

Comment thread crates/project/src/lsp_store/code_lens.rs Outdated

Comment thread crates/editor/src/code_lens.rs Outdated

Comment thread crates/editor/src/code_lens.rs Outdated

Comment thread crates/editor/src/code_lens.rs Outdated

Code review fixes

7000095

Co-authored-by: Lukas Wirth <me@lukaswirth.dev>

SomeoneToIgnore force-pushed the kb/code-lens branch from cc76586 to 7000095 Compare April 20, 2026 21:22

Move out resolve from code lens fetching

aaac10b

Veykril approved these changes Apr 21, 2026

View reviewed changes

SomeoneToIgnore merged commit 76883bb into main Apr 22, 2026
31 checks passed

SomeoneToIgnore deleted the kb/code-lens branch April 22, 2026 17:02

mustakimali mentioned this pull request Apr 23, 2026

Add CodeLens UI #53016

Closed

kathbigra pushed a commit to kathbigra/zed that referenced this pull request May 10, 2026

Support code lens in the editor (zed-industries#54100)

dbff974

kathbigra pushed a commit to kathbigra/zed that referenced this pull request May 10, 2026

Handle lens navigation targets similar to code actions (zed-industrie…

ff59b05

…s#54664) Follow-up to zed-industries#54100 Release Notes: - N/A

SomeoneToIgnore mentioned this pull request May 27, 2026

Fall back to default text when no command is available for the resolved lens #57790

Merged

This was referenced May 27, 2026

Fall back to default text when no command is available for the resolved lens (#57790) (cherry-pick to stable) #57796

Merged

Fall back to default text when no command is available for the resolved lens (#57790) (cherry-pick to preview) #57797

Merged

jasonsmithio pushed a commit to paddleboarddev/paddleboard that referenced this pull request May 31, 2026

Handle lens navigation targets similar to code actions (#54664)

d17558d

Follow-up to zed-industries/zed#54100 Release Notes: - N/A

This was referenced Jun 27, 2026

Fix code lens not being resolved in remote workflows #59999

Merged

Refresh code lens after dynamic registration #60009

Merged

jonx pushed a commit to jonx/zed-aros that referenced this pull request Jul 17, 2026

Support code lens in the editor (zed-industries#54100)

c0a1732

jonx pushed a commit to jonx/zed-aros that referenced this pull request Jul 17, 2026

Handle lens navigation targets similar to code actions (zed-industrie…

63065eb

…s#54664) Follow-up to zed-industries#54100 Release Notes: - N/A

SomeoneToIgnore mentioned this pull request Jul 28, 2026

Add Go implementation count code lenses #61760

Closed

5 tasks

jolutz pushed a commit to jolutz/zed that referenced this pull request Aug 8, 2026

Support code lens in the editor (zed-industries#54100)

a150ab3

Navigation Menu

Uh oh!

Uh oh!

Support code lens in the editor - #54100

Support code lens in the editor#54100
SomeoneToIgnore merged 3 commits into
mainfrom
kb/code-lens

SomeoneToIgnore commented Apr 16, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mustakimali commented Apr 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Uh oh!

Conversation

SomeoneToIgnore commented Apr 16, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mustakimali commented Apr 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants