Neomacs: A GPU-Powered Emacs Rewrite in Rust That Is Still Finding Its Footing
NEO Emacs (WIP): GPU powered Emacs written in Rust with a modern display engine. Aiming for modern design & multi-threaded Elisp, 10x performance, zero-pause concurrent GC and 100% Emacs compatibility.
At a glance
- What is it?
- Neomacs is a hard fork of GNU Emacs that replaces the C core with Rust and moves rendering to the GPU, aiming for 100% compatibility while adding animations and inline media. It is a promising but unfinished project with real limitations.
- Who is it for?
- Adopt Neomacs if you are a developer or Emacs enthusiast who wants to experiment with a GPU-accelerated Emacs and can tolerate missing features and breaking changes. Do not use it as your primary editor yet if you rely on a stable, fully compatible Emacs environment.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Neomacs Actually Replaces
Neomacs is not a new editor that merely mimics Emacs. It is a hard fork of GNU Emacs, with the Lisp tree synced to emacs-31.0.90, and the C core fully replaced by Rust. That means the Elisp evaluator, bytecode VM, garbage collector, portable dump, and editor internals are all reimplemented in memory-safe Rust. The README claims that around 300,000 lines of C are replaced, and specifically that about 4,000 lines of Rust replace roughly 50,000 lines of xdisp.c, the display engine. The stated goal is 100% compatibility with the existing Emacs ecosystem: your init.el, your packages, your muscle memory. For anyone who has lived with Emacs's C internals, the appeal is obvious: the parts that were historically hard to hack are now open to a modern language.
How the GPU Display Engine Works
The core architectural shift is that everything runs across two threads. The Emacs thread owns the Elisp runtime and editor state, while a separate render thread owns the GPU. Rendering is done via wgpu, which abstracts over Vulkan, Metal, DX12, and OpenGL. The README mentions that text, images, and effects are rendered on the GPU, and that inline media like 4K video and images are decoded on the GPU, not on the main thread. Zero-copy DMA-BUF is used for video and browser content. This is a fundamental departure from GNU Emacs, where the display engine is tightly coupled to the Lisp thread and rendering happens on the CPU. The two-thread model is meant to keep the UI responsive even when Elisp is busy, but it also introduces complexity: the render thread must communicate with the Emacs thread, and the README notes that the GPU display and layout engine is still in an early, improving state.
Getting Neomacs Running
The easiest path is to download a prebuilt package from the Releases page. For Linux, there are AppImage, .deb, .rpm, and tarball packages for x86_64 and aarch64. macOS has experimental .dmg, .zip, and .tar.gz builds for Apple Silicon, and Windows has an experimental installer and portable zip. Building from source is also documented. The commands are: git clone https://github.com/eval-exec/neomacs && cd neomacs, then optionally nix develop --accept-flake-config to enter a dev shell with dependencies, then cargo xtask fresh-build --release. That command compiles Rust, bootstraps Elisp, and generates the portable dump. Finally, run ./target/release/neomacs. The same binary supports a terminal mode with neomacs -nw. There is no mention of a package manager like MELPA or ELPA for installing Neomacs itself, so you are expected to use the release artifacts or build it yourself.
Compatibility Status and the Oracle Test Approach
The project's compatibility claim is backed by an unusual testing strategy: GNU Emacs itself serves as the test oracle. Every rewritten subsystem is diffed against GNU Emacs, and real-world configs like Doom Emacs are used as a daily test bed. The status table lists 100% GNU Emacs compatibility at roughly 95%, with the last gaps still being closed. That is a concrete, honest figure, but it also means you cannot assume your favorite package will work. The README warns that this is a work in progress, with rough edges, breaking changes, and missing features. If you rely on a niche package that touches low-level C hooks, it may not work yet. The oracle approach is sound in principle, but it only verifies behavior that the test suite covers; it cannot guarantee that every edge case in the entire ecosystem is handled.
The Multi-Threaded Elisp Promise and Its Current Reality
One of the headline promises is true multi-threaded Elisp and a zero-pause concurrent GC. The status table shows that true multi-threaded Elisp is still in the design and research phase, with experimental attempts. The zero-pause GC is maturing but not finished. This is a significant caveat. GNU Emacs has a single-threaded Lisp interpreter, and many packages assume that. Even if Neomacs achieves multi-threading, it may break packages that rely on global state or assume atomicity. The README does not provide details on how the GC will be made concurrent or how it will interact with the existing Elisp semantics. For now, the performance gains are not yet realized, and the project is upfront about that. The 10x performance claim is an ambition, not a measured result.
Animations and Media as a Differentiating Feature
The GPU engine enables features that are impossible in stock Emacs: cursor, buffer-switch, and scroll animations rendered at display refresh rate. The README lists 8 cursor modes, 21 scroll effects, and 10 buffer transitions, all configurable from Elisp. Inline 4K video playback via GStreamer and VA-API, GPU-decoded images, a WPE WebKit browser, and an embedded Alacritty terminal are all demonstrated. These are not just cosmetic; they show that the display engine is genuinely different. However, the README labels these as experimental and improving. The animations are inspired by Neovide, which is a good reference point for what is possible. But for a text editor, animations are a nice-to-have, not a core requirement. The real question is whether the GPU engine provides a tangible speedup for everyday editing, and that is not yet demonstrated.
Licence and Maintenance Considerations
Neomacs is licensed under GPL-3.0, the same as GNU Emacs. That means it is free software, and you can modify and redistribute it under the same license. The project is a hard fork, so it inherits the GPL obligations from Emacs. In terms of maintenance, the project is active, with recent releases (v0.0.15 in August 2026, v0.0.14 in July, v0.0.13 in July). The README acknowledges that it is a long-term project and asks for sponsorship. The release cadence suggests steady development, but the status table shows many areas are still early or in design. Upgrading between versions may involve breaking changes, as the README warns. There is no documentation on how to migrate configs or packages, so expect to re-test your setup after each update. The build process with cargo xtask fresh-build is straightforward, but it requires Rust and system dependencies, which may be a barrier for non-developers.
Alternatives and the Right Tool for the Job
The most obvious alternative is GNU Emacs itself, which is stable, mature, and has a vast ecosystem. If you need a reliable editor today, GNU Emacs is the safer choice. Another alternative is Neovide, which is a GPU-accelerated frontend for Neovim, not Emacs. Neovide provides cursor animations and smooth scrolling, but it does not aim for 100% compatibility with Emacs Lisp. If you are an Emacs user who wants GPU rendering, Neomacs is the only project attempting this, but it is not ready for production. For developers who want to hack on the display engine, Neomacs offers a unique opportunity: the entire frontend, from render effects down to WGSL shaders, is exposed to Elisp. That is a level of hackability that GNU Emacs cannot provide. But for most users, the trade-off between stability and novelty is not yet worth it.
Editorial conclusion
Adopt Neomacs if you are a developer or Emacs enthusiast who wants to experiment with a GPU-accelerated Emacs and can tolerate missing features and breaking changes. Do not use it as your primary editor yet if you rely on a stable, fully compatible Emacs environment. First verify that your init.el and essential packages work, check the current state of the oracle test suites (reported at ~95%), and confirm that your platform (Linux, macOS, or Windows) is supported. The project is under active development, so expect changes and consult the FAQ and architecture docs before committing.
Community notes