Vision

The design goal, in one line: a CLI IDE that is maximally powerful with zero user configuration — install the binary, open a project, and have the full power of a graphical IDE in the terminal, with the muscle memory of Spacemacs and JetBrains already wired in.

zmax is a modal IDE in Rust, built on a tree-sitter + LSP engine. It aims at a single, opinionated target: the most capable out-of-the-box terminal IDE you can brew install.

The four pillars

1. Zero user config. Everything works on first launch. No init.el, no init.vim, no plugin manager, no Mason, no :PackerSync, no external language-server bootstrap ritual. The defaults are the product. (You can still customize — keymaps, themes, settings, ~/.zmax/init.el — but you should never have to in order to be productive.)

2. Maximum power. Not a minimal editor you grow into — the full IDE surface ships in the single static binary: LSP (completion, diagnostics, hover, inlay hints, rename, code actions), a DAP debugger, tree-sitter for the bundled languages, a fuzzy file picker, a project file tree, a real PTY terminal, magit-style git, diff/merge tooling, run configurations, a minimap, narrowing, folding, multiple selections, an org-mode agenda, a hex editor, settings/theme/keymap editors, a searchable help browser, and ten embedded scripting languages with a live REPL (elisp, vimscript, awk, zsh, stryke, ruby, php, python, node, arb) — no FFI, no external executables.

3. CLI-first, native. Terminal is the primary surface, not a fallback. No Electron, no DOM, no Node. Native-compiled Rust that runs in an SSH session on a Raspberry Pi as happily as on a workstation — open a 200 MB file, a line of minified JS, or ShiftJIS-encoded text and edit it without flinching.

4. Parity with Spacemacs and JetBrains. These are the two reference workflows. A Spacemacs user's SPC leader tree and a JetBrains user's keymap and IDE actions should both just work — same key, same result — so neither has to relearn anything to switch.

Is the goal achieved?

Substantially, yes — and the project refuses to claim it without proof.

Coverage is not asserted by hand; it is re-derived from zmax source on every report run and measured against the exhaustive, cited feature inventories of the other terminal editors — Vim/Neovim, Emacs, Spacemacs and JetBrains, and beside them kakoune, vis, sam, ed, nvi, vile, mg, nano, micro, mcedit, ne, dte and the Neovim distributions — each parsed from that tool's own documentation or, where its docs are prose, from the table its build reads (vile's cmdtbl, nano's src/global.c, mc's shipped keymap). A mapping that points at non-existent code is flagged as broken, not counted. See port/README.md for the honesty contract.

The headline measure is functionality coverage — distinct editor capabilities, counted once regardless of how many ancestor editors expose the same feature (it answers "what can zmax do," not "how many keys overlap"). By that measure the great majority of the tracked capability surface is implemented today, with only a handful of genuine gaps remaining. Per the muscle-memory tables, JetBrains and Spacemacs are both well into the high range — every cited JetBrains action is at least partially covered, and the Spacemacs SPC tree is largely complete — while the Emacs chord surface is intentionally low because zmax is modal (vim keys), not a chord editor.

Live numbers — denominator, ported, partial, broken, and the per-source and per-capability breakdowns — are in the generated reports, never hardcoded here so they cannot go stale:

• docs/port_report.md — full capability + per-source coverage
• docs/keybinding_report.md — the key-press surface
• docs/spacemacs_gaps.md — remaining Spacemacs deltas

What "achieved" does not mean

Honesty cuts both ways:

• Not 100% parity with three giant editors. The Emacs manual denominator includes Dired, Gnus, Calc, TeX-mode and games; zmax deliberately does not chase that tail. "Parity" here means the Spacemacs and JetBrains daily workflows, not every esoteric command in every ancestor.
• Refactoring is the known weak area. Symbol-level refactors (extract, inline, change-signature) are mostly LSP-delegated and only partially wired; this is the largest open gap and the clearest place new work moves the number.
• "Zero config" is the standard, and regressions count as bugs. Any feature that needs a manual setup step to function is treated as not-yet-meeting the goal, not as "configurable."

Non-goals

• Not "everything for everyone." zmax has an opinion (modal, selection → action, batteries-included). It is not trying to be a blank canvas.
• Not a code-golf keymap. Consistency and memorability beat saving a keystroke.
• Not a GUI app. Native terminal first; no Electron/DOM.
• Not config-mandatory. Customization is allowed and supported, but the measure of success is how much you can do having configured nothing.