Zed, Vim, And The Problem Of Editors

Zed’s Vim mode is being built not as a compatibility layer for Neovim, but as a feature set that fits Zed’s own architecture—especially its multiplayer-first data model. Thorston, now at Zed after work at Sourcegraph, describes how the editor’s core concepts (buffers, CRDTs, and rendering loops) force trade-offs: some Vim behaviors can be approximated, but others—like Vim’s hidden buffers, command-line piping, and keystroke-level macros—don’t map cleanly onto Zed’s action/binding system.

The practical result is a “merge what matters” approach. Zed’s Vim mode is implemented as a single Rust crate, and development has focused on closing the gaps users notice most: motions that take counts (for example, variants of “z z” behavior), dot-repeat support, visual-mode indentation edge cases, and missing registers/marks. The team also uses Neovim’s headless mode as a reference for golden tests: simulated keystrokes run in Neovim to produce expected cursor/selection outcomes, then the same keystrokes are replayed in Zed and outputs are compared. That testing strategy is meant to keep the experience close where it counts, even while the underlying mechanics differ.

Beyond Vim compatibility, the conversation connects editor design to the realities of developer tooling at scale. Thorston frames developer tools as a place where engineering can directly move the needle—unlike many B2C products where marketing can dominate. He also emphasizes that “APIs” in developer tools aren’t just network interfaces; they include CLI flags, settings schemas, and editor configuration formats. In that mindset, editor features become contracts with strong user opinions, which explains why text editors generate intense loyalty and backlash when behavior changes.

Linux support becomes another lens on the same theme: the experience is “pretty good” on Wayland, but X11 performance work is tricky and may require changes to Zed’s event loop. The Linux port also faces fragmentation—different windowing stacks, legacy X11 layers, and desktop environments with their own rules for window decorations. Collaboration features are still incomplete on Linux, with audio/video and screen-sharing called out as especially hard.

Finally, the discussion highlights why editor features behave like a “fat tail”: small capabilities can be mission-critical for specific users. A ticket from GitHub cofounder Scott Shone about Vim replace modes (lowercase/uppercase “r”) drew a $500 bounty after community interest proved it wasn’t niche. Similar stories come up around built-in Git integration versus terminal workflows, showing that even when a feature is optional, enough users depend on it that missing it can feel like a deal-breaker.

Taken together, the interview paints editor development as a balancing act between architectural correctness, compatibility expectations, and platform constraints—where the hardest problems aren’t just rendering speed or keybindings, but the long list of “small” behaviors that determine whether a community feels at home or angry.