DinoandGitHub
e017293aed
The work introduced in https://github.com/zed-industries/zed/pull/54496 updated the `command_aliases` schema, adding support for auto-completion action names when editing the settings file. However, it didn't take into consideration the case where the user is simply creating an alias to an arbitrary string. These changes introduce a new `CommandAliasTarget` newtype for which the json schema is either a registered action name, from `ActionName` or any arbitrary string, as those are supported by the `command_aliases` setting. Updating the `ActionName` schema to accept any arbitrary string would break the guarantees we have on the keymap binding schema, so that's why a new schema was introduced. Lastly, trying to set `CommandAliasTarget::json_schema` to a simply `anyOf` with either the registered action name or a string that is not a registered action name, like shown below, broke deprecation warnings, hence why we're still doing the approach of only building `CommandAliasTarget` at runtime. ```json { "anyOf": [ { "$ref": "#/$defs/ActionName" }, { "type": "string", "not": { "$ref": "#/$defs/ActionName" }}, ] } ``` 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) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Release Notes: - Fixed validation of `command_aliases` setting to avoid showing warnings when aliasing to an arbitrary string
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.