zed/crates/vim
Xin Zhao 3ed1c32bf9
editor: Fix diagnostic rendering when semantic tokens set to full (#53008)
Self-Review Checklist:

- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable

Closes #50212

There are two unreasonable coupling account for this issue, the coupling
of `use_tree_sitter` with `languge_aware` in

7892b93279/crates/editor/src/element.rs (L3820-L3822)
and the coupling of `language_aware` with `diagnostics` in
7892b93279/crates/language/src/buffer.rs (L3736-L3746)

Because of these couplings, when the editor stops using Tree-sitter
highlighting when `"semantic_tokens"` set to `"full"`, it also
accidentally stops fetching diagnostic information. This is why error
and warning underlines disappear.

I’ve fixed this by adding a separate `use_tree_sitter` parameter to
`highlighted_chunks`. This way, we can keep `language_aware` true to get
the diagnostic data we need, but still decide whether or not to apply
Tree-sitter highlights. I chose to fix this at the `highlighted_chunks`
level because I’m worried that changing the logic in the deeper layers
of the DisplayMap or Buffer might have too many side effects that are
hard to predict. This approach feels like a safer way to solve the
problem.

Release Notes:

- Fixed a bug where diagnostic underlines disappeared when
"semantic_tokens" set to "full"

---------

Co-authored-by: Kirill Bulatov <kirill@zed.dev>
2026-04-07 14:15:33 +00:00
..
src editor: Fix diagnostic rendering when semantic tokens set to full (#53008) 2026-04-07 14:15:33 +00:00
test_data vim: Fix % for multiline comments and preprocessor directives (#53148) 2026-04-07 02:51:54 +00:00
Cargo.toml theme: Split out theme_settings crate (#52569) 2026-03-27 14:41:25 +01:00
LICENSE-GPL
README.md Correct other end visual block functionality (#27678) 2025-03-28 20:52:38 +00:00

This contains the code for Zed's Vim emulation mode.

Vim mode in Zed is supposed to primarily "do what you expect": it mostly tries to copy vim exactly, but will use Zed-specific functionality when available to make things smoother. This means Zed will never be 100% vim compatible, but should be 100% vim familiar!

The backlog is maintained in the #vim channel notes.

Testing against Neovim

If you are making a change to make Zed's behavior more closely match vim/nvim, you can create a test using the NeovimBackedTestContext.

For example, the following test checks that Zed and Neovim have the same behavior when running * in visual mode:

#[gpui::test]
async fn test_visual_star_hash(cx: &mut gpui::TestAppContext) {
    let mut cx = NeovimBackedTestContext::new(cx).await;

    cx.set_shared_state("ˇa.c. abcd a.c. abcd").await;
    cx.simulate_shared_keystrokes(["v", "3", "l", "*"]).await;
    cx.assert_shared_state("a.c. abcd ˇa.c. abcd").await;
}

To keep CI runs fast, by default the neovim tests use a cached JSON file that records what neovim did (see crates/vim/test_data), but while developing this test you'll need to run it with the neovim flag enabled:

cargo test -p vim --features neovim test_visual_star_hash

This will run your keystrokes against a headless neovim and cache the results in the test_data directory. Note that neovim must be installed and reachable on your $PATH in order to run the feature.

Testing zed-only behavior

Zed does more than vim/neovim in their default modes. The VimTestContext can be used instead. This lets you test integration with the language server and other parts of zed's UI that don't have a NeoVim equivalent.