NEO Emacs: a Rust and wgpu rewrite of Emacs that keeps your init.el

What NEO Emacs is trying to fix, and who it is aimed at

The pitch is narrow and specific. Emacs users get a mature Lisp environment bolted to a C core that is roughly 300,000 lines and a display engine, xdisp.c, of about 50,000 lines. NEO Emacs rebuilds both in Rust, with the display path on the GPU through wgpu, and keeps GNU Emacs itself as the test oracle so each rewritten subsystem is checked against the original's behaviour. The README states the Lisp tree is synced to emacs-31.0.90 and calls the result a hard fork.

The audience is the person who already has an init.el they are unwilling to abandon. The README's framing is compatibility as a contract: your config, your packages, your muscle memory. Real-world configs such as Doom Emacs are described as the daily test bed, which is a stronger claim than a synthetic benchmark suite, though it is the project's own description of its process.

There is a second audience: people who want to hack below the Lisp line. In GNU Emacs, the README argues, hackability ends where the C display engine begins. NEO Emacs exposes the frontend to Elisp, down to WGSL shaders and surfaces. If you have ever wanted to change how a frame is composited without patching C, that is the draw.

Two threads, one Lisp runtime, and a GPU on the other side

The architecture section is short but concrete: everything runs in Rust across two threads. The Emacs thread owns the Elisp runtime and editor state; the render thread owns the GPU. That split is what makes the animation catalogue possible at all, because the renderer is not waiting on Lisp evaluation to draw a cursor.

The crate layout in Cargo.toml backs this up with more detail than the README gives. neomacs-layout-engine, neomacs-renderer-wgpu, neomacs-font-materializer and neomacs-display-runtime sit alongside neovm-core, neovm-host-abi and neovm-worker. The naming separates the VM side from the display side, and the presence of neomacs-display-protocol implies the two threads talk over a defined protocol rather than sharing mutable state. That is a plausible reading of the workspace, not something the README spells out.

Media handling is where the design gets interesting. Inline 4K video uses GStreamer with VA-API, images are GPU-decoded, the browser is WPE WebKit, and the terminal is described as Alacritty-based. All of it is zero-copy via DMA-BUF. The Cargo.toml capability table shows this is platform-gated at build time: Linux gets cargo-features = ["video"] with video-backend = "linked-gstreamer", macOS gets ["webview"] with video-backend = "none" because the inline browser is the system WKWebView, and Windows gets neither. So "inline video" is not a cross-platform feature, and the build system is honest about that.

Installing NEO Emacs and getting a first frame on screen

The README points system-package users at the Releases page. Linux has AppImage, .deb, .rpm and tarball builds for x86_64 and aarch64. macOS is marked experimental with .dmg, .zip and .tar.gz for Apple Silicon. Windows is also experimental, with an installer .exe and a portable .zip. There is also an install.sh at the repository root, though the README does not document what it does.

Building from source is documented with a fenced example. The repository ships a Nix flake, and the README calls the dev shell optional but recommended because it brings in all dependencies:

git clone https://github.com/eval-exec/neomacs && cd neomacs

# Optional (recommended): repo dev shell with all dependencies
nix develop --accept-flake-config

After that, the build goes through the workspace's own xtask rather than plain cargo build. The comment in the README says this compiles Rust, bootstraps Elisp, and generates the portable dump:

cargo xtask fresh-build --release

./target/release/neomacs

You should end up with a neomacs binary under target/release. The README notes that platform dependencies for Arch, macOS and Nix/Cachix, plus the test suites, live in docs/building.md, which is where to look when the build fails on a missing native library. For a terminal-only session, the same binary takes -nw:

./target/release/neomacs -nw

The README's status table describes the TUI renderer as usable and being polished, so the terminal path exists but is not the headline. If you want to confirm your config survives before trusting the GUI, -nw is the cheaper first test.

Where NEO Emacs is not ready, by its own status table

The status table is unusually candid and should be read before anything else. The compatibility row reads "~95%, closing the last gaps". Five percent of a Lisp surface as large as Emacs is not a rounding error; it is the difference between your workflow working and one package failing in a way that is hard to attribute.

Several subsystems are marked early. The Elisp-hackable frontend, meaning GPU shaders and surfaces exposed to Lisp, is "early, expanding". The GPU display and layout engine that replaces xdisp.c is "early, improving". The Rust Elisp runtime, covering the evaluator, bytecode VM and portable dump, is "refactoring, testing, improving". Zero-pause GC is "maturing", and the README's headline goal of true multi-threaded Elisp is only "designing, researching, experimental attempts". The 10x performance claim in the repository description is not backed by a published number in this material; the performance row says profiling, benchmarking, tuning.

Cross-platform support is the other boundary. The README says Linux and macOS come first, Windows is awaiting testing, and WASM, Android and iOS are planned. The Cargo.toml capability table confirms Windows ships with no video and no webview features. If your team is on Windows, this is not the tool yet. If you need the terminal path to be as polished as the GUI, the status table tells you it is not.

NEO Emacs versus GNU Emacs, and where Remacs fits

The obvious comparison is GNU Emacs itself, and the difference is not features but the layer being replaced. GNU Emacs keeps its C core and draws through xdisp.c. NEO Emacs throws out the C core entirely, runs a Rust evaluator and bytecode VM, and renders through wgpu on Vulkan, Metal, DX12 or GL. The README claims roughly 4,000 lines of Rust replace roughly 50,000 lines of xdisp.c, which is a claim about surface area rather than a measured comparison.

The practical difference for a user is what you can change. In GNU Emacs, changing the display engine means patching C and rebuilding. In NEO Emacs, the README says the frontend is open to Elisp, including WGSL shaders. That is a real architectural difference, and it is also the part marked "early" in the status table, so the capability exists before it is comfortable.

Remacs is the other name people search for, and the contrast is instructive. Remacs was the earlier attempt to move Emacs's C into Rust; the README does not mention it, so the comparison here is limited to what this repository states about itself. NEO Emacs goes further in one respect: it does not stop at the core, it also replaces the display engine and adds a GPU media pipeline. That is a larger bet, and it explains why the project is a hard fork synced to a specific Emacs version rather than a patch series.

Licence, forks, and the cost of tracking upstream

NEO Emacs is GPL-3.0, the same licence as Emacs, and the README states this explicitly alongside a COPYING file at the repository root. For most users this changes nothing. For anyone embedding NEO Emacs in a product, the GPL obligations are the same shape as they would be with GNU Emacs, and the project gives no legal guidance beyond the licence identifier. Treat that as a question for your own counsel, not something the README answers.

The maintenance cost is the part worth thinking about before adopting. This is a hard fork with the Lisp tree synced to emacs-31.0.90, which means upstream Emacs changes have to be pulled in and reconciled against a rewritten core. The release cadence visible in the repository is fast: v0.0.13 on 2026-07-18, v0.0.14 on 2026-07-24, v0.0.15 on 2026-08-10, and the last push to main was on 2026-08-10. Frequent point releases at 0.0.x signal active work, and they also signal that the interface is not settled. The README warns about breaking changes directly.

There is a funding dimension too. The README describes NEO Emacs as a long-term project taking significant ongoing work and links GitHub Sponsors. That is a fair signal about how the work is sustained, and it is worth weighing if you plan to depend on it.

Editorial conclusion

NEO Emacs is worth adopting if you already live in Emacs and want to read or modify the render path itself, or you want inline video, WebKit and a GPU terminal inside buffers. It is not the right editor for anyone who needs a dependable daily driver today: the README labels the whole project a work in progress with breaking changes, Windows support is still awaiting testing, and the compatibility suite is described as roughly 95 percent. Before you commit, install a release build, start it with your real init.el, and run the oracle test crates (neovm-oracle-tests, neomacs-test-oracle) against the subsystems you depend on.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes