76d18f3cd2
Some checks are pending
CI / check_docs_only (push) Waiting to run
CI / Check Postgres and Protobuf migrations, mergability (push) Waiting to run
CI / Check formatting and spelling (push) Waiting to run
CI / (macOS) Run Clippy and tests (push) Blocked by required conditions
CI / (Linux) Run Clippy and tests (push) Blocked by required conditions
CI / (Linux) Build Remote Server (push) Blocked by required conditions
CI / (Windows) Run Clippy and tests (push) Blocked by required conditions
CI / Create a macOS bundle (push) Blocked by required conditions
CI / Create a Linux bundle (push) Blocked by required conditions
CI / Create arm64 Linux bundle (push) Blocked by required conditions
CI / Auto release preview (push) Blocked by required conditions
Deploy Docs / Deploy Docs (push) Waiting to run
Docs / Check formatting (push) Waiting to run
Script / ShellCheck Scripts (push) Waiting to run
This is harmful for user experience and at best requires a user setting. This was committed as part of https://github.com/zed-industries/zed/pull/21739 however that change had no relevant release notes and no relevant settings. The issue #22343 shows how this can result in user experience regression: deleting a text fragment can reinsert it back, and it's thus unclear if the deletion has even worked. Maybe this can be reenabled in some very restrictive setup, and put behind a setting, but it can't be unconditional. Completions should activate when the user signals intent of entering code - for example, if instead of `de` to delete a fragment, I press `ce` to replace it, I would naturally expect inline completions to show up. Note: The linked PR added more code in vim crate to refresh inline completions in normal mode. I'm keeping that code around in this commit, so that this can be the minimal fix to the linked issue -- with the assumption that maybe there's some way in the future to reenable this in a subset of cases that don't result in confusing / broken UX. If that is not true the code might need further cleanup. Let me know if you'd rather see removal of those changes in this PR as well. Closes #22343. Release Notes: - Fixes inline completions showing up in Vim normal mode. |
||
|---|---|---|
| .. | ||
| 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.
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.