01ec6e0f77
This adds a "workspace-hack" crate, see [mozilla's](https://hg.mozilla.org/mozilla-central/file/3a265fdc9f33e5946f0ca0a04af73acd7e6d1a39/build/workspace-hack/Cargo.toml#l7) for a concise explanation of why this is useful. For us in practice this means that if I were to run all the tests (`cargo nextest r --workspace`) and then `cargo r`, all the deps from the previous cargo command will be reused. Before this PR it would rebuild many deps due to resolving different sets of features for them. For me this frequently caused long rebuilds when things "should" already be cached. To avoid manually maintaining our workspace-hack crate, we will use [cargo hakari](https://docs.rs/cargo-hakari) to update the build files when there's a necessary change. I've added a step to CI that checks whether the workspace-hack crate is up to date, and instructs you to re-run `script/update-workspace-hack` when it fails. Finally, to make sure that people can still depend on crates in our workspace without pulling in all the workspace deps, we use a `[patch]` section following [hakari's instructions](https://docs.rs/cargo-hakari/0.9.36/cargo_hakari/patch_directive/index.html) One possible followup task would be making guppy use our `rust-toolchain.toml` instead of having to duplicate that list in its config, I opened an issue for that upstream: guppy-rs/guppy#481. TODO: - [x] Fix the extension test failure - [x] Ensure the dev dependencies aren't being unified by Hakari into the main dependencies - [x] Ensure that the remote-server binary continues to not depend on LibSSL Release Notes: - N/A --------- Co-authored-by: Mikayla <mikayla@zed.dev> Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com> |
||
|---|---|---|
| .. | ||
| src | ||
| test_data | ||
| Cargo.toml | ||
| LICENSE-GPL | ||
| README.md | ||
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.