Katie GeerandZed Zippy
2d26605348
## Summary Adds a "Notification Shown" telemetry event that fires whenever a user-facing notification is displayed in Zed. This helps the team understand error patterns, notification frequency, and which parts of the application generate the most notifications. ## Event Schema | Property | Type | Description | |----------|------|-------------| | `notification_type` | `string` | `"error"` or `"notification"` | | `source` | `string` | Origin category (e.g., `lsp`, `git`, `settings`, `editor`) | | `lsp_name` | `string?` | Language server name (only for LSP notifications) | | `level` | `string?` | Severity: `"critical"`, `"warning"`, or `"info"` | | `has_actions` | `bool` | Whether the notification has action buttons | | `notification_id` | `string` | Debug string of the NotificationId | | `is_auto_dismissing` | `bool` | Whether the notification auto-dismisses | ## NotificationSource Categories A new `NotificationSource` enum categorizes notifications by origin: - `lsp` - Language server notifications - `settings` - Settings/keymap parse errors - `update` - App updates, release notes - `extension` - Extension suggestions/errors - `git` - Git operations, commit errors - `project` - Project-level issues - `collab` - Collaboration notifications - `remote` - SSH/remote project errors - `file` - File access errors - `editor` - Editor operations (search, encoding) - `agent` - AI assistant notifications - `cli` - CLI installation - `system` - Generic fallback ## Privacy **Message content is intentionally not included** in telemetry because: - LSP messages come from external servers and may contain file paths or error chains - Error messages may contain sensitive paths or API-related information - The metadata alone provides sufficient insight for error tracking ## Implementation Updated function signatures to include `NotificationSource`: - `show_notification(id, source, cx, build_fn)` - `show_toast(toast, source, cx)` - `show_error(err, source, cx)` - `show_app_notification(id, source, cx, build_fn)` - `notify_err(workspace, source, cx)` - `notify_async_err(source, cx)` - `notify_app_err(source, cx)` - `detach_and_notify_err(source, window, cx)` Release Notes - N/A (internal telemetry change) --------- Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.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.