b7d35e528a
Update the JSON schema generated for the settings file in order to be able to provide the list of valid actions when editing the values for the `command_aliases` setting. While reviewing https://github.com/zed-industries/zed/pull/52892 , I noticed that, even though we already have support for this in the keymap file, we don't support it for the `command_aliases` setting, so went ahead and refactored this a bit such that the existing functionality for the keymap file JSON schema could also be re-used for the `command_aliases` setting. Here's a quick big-picture breakdown of the relevant changes: * Add `settings_content::ActionName` newtype, representing a simple named action without arguments. The `settings_content::ActionName::build_schema` function can be used to build the schema of all possible action names. * Add `settings_content::ActionWithArguments` newtype, representing an action with arguments. This was mostly done so as to keep both action without arguments and action with arguments newtypes together, even though we don't have `settings_content::ActionWithArguments::build_schema`, as it is only used by the keymap schema generation logic and probably doesn't warrant moving it here right now. * Update both `settings_content::WorkspaceSettingsContent::command_aliases` and `workspace::workspace_settings::WorkspaceSettings::command_aliases` to now be of type `HashMap<String, ActionName>` such that, when the json schema for `command_aliases` is generate, it'll now reference the `#/$defs/ActionName` schema. * Update `SettingsStore::json_schema` so as to populate the `#/$defs/ActionName` schema at runtime, replacing it with the actual list of valid action names. 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: - Added support for auto-completing action names on `command_aliases` setting |
||
|---|---|---|
| .. | ||
| 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.