João Soaresanddino
0361eff982
# Objective Fixes #58736 Pause the debugger on a breakpoint, switch your theme, and the active debug line keeps its old highlight color until you step again or restart Zed. ## Solution The highlight stores a concrete color grabbed from the theme back when `go_to_active_debug_line` ran. A theme switch goes through `theme_changed`, which refreshes brackets, semantic tokens, and outline symbols but never re-applies that highlight, so it stays stale. Re-running `go_to_active_debug_line` from `theme_changed` re-resolves the color against the current theme. ## Testing Added a regression test in `debugger_ui` that stops at a debug line, swaps the theme's `editor.debugger_active_line.background`, and checks the highlight follows. It fails on `main` and passes with the fix. Also tested by hand on Windows: started a debugpy session, paused at a breakpoint, switched themes from the theme selector, and watched the active line recolor live without stepping or restarting. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [ ] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable ## Showcase Paused at a breakpoint, switching themes from the theme selector. | Before | After | | --- | --- | | https://github.com/user-attachments/assets/653a7e1b-3a99-4316-b1c9-b16ed7a7a8ba | https://github.com/user-attachments/assets/22a4c876-30f2-44c5-aad9-0f860639074c | --- Release Notes: - Fixed the active debug line color not updating when switching themes while the debugger is paused ([#58736](https://github.com/zed-industries/zed/issues/58736)). --------- Co-authored-by: dino <dinojoaocosta@gmail.com>
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.