A 2.96-million-line tree preserves Emacs Lisp over a Rust core
NEO Emacs is a hard fork, not a new editor borrowing Emacs keybindings. The project retains the Lisp side of GNU Emacs and replaces the C core with Rust implementations of the evaluator, bytecode machine, garbage collector, buffers, windows, processes, layout, and rendering. That choice explains the size of our checkout: about 2.96 million source lines across 12,117 files. Much of the familiar ecosystem remains present because compatibility depends on running the same Lisp, not imitating its surface.
The visible change is a wgpu display engine. The README describes GPU text and images, inline video, an embedded browser, a terminal buffer, shaders, and configurable cursor or buffer animations. The same binary also has a terminal mode. These features make NEO Emacs more than a language-runtime exercise, but they do not settle the editor question. An Emacs replacement succeeds when a user's existing config behaves correctly for months, not when a demo renders a 4K clip.
The README's 95 percent compatibility estimate still leaves daily gaps
The status table estimates GNU Emacs compatibility at about 95 percent and labels the editor a work in progress. GNU Emacs acts as the test oracle: parity suites compare behavior, terminal grids, and graphical results against a pinned upstream version. This is the right standard for a hard fork because a package can load successfully and still draw the wrong mode line, bind a different key, or change subtle Lisp behavior. The project's own warning about missing features should carry more weight than the percentage.
Compatibility also creates a moving target. Issue 271 tracks synchronization with GNU Emacs and records an Emacs 31.1 Lisp baseline while upstream master has moved further. The issue calls for oracle-gated sync work rather than copying files blindly. Issue 177 shows the user-facing side of the problem: an older font configuration produces different Chinese font rendering than Emacs. NEO Emacs can preserve an init.el and still diverge in the behavior that configuration was written to control.
What happened when we ran it
Our measurement setup used commit 83c5895 in a 3-CPU, 12 GB Rust sandbox. Installing 697 packages succeeded in 47 seconds. The checkout occupied 265.2 MB before build output. A release build then ran for 900 seconds without finishing, so we cannot claim a successful compile or state how much longer it needed.
The test command also reached the 900-second cap. Before timeout, the log showed Lisp language files loading and marked startup::tests::gnu_startup_restores_meta_and_ctl_x_bindings as failed. It continued printing load paths and dump-mode messages, which means the process had not reached a final suite summary. The log does not establish the cause of that failure. Our run proves that this checkout was expensive to verify in the stated sandbox and did not produce a clean result within 15 minutes.
Version 0.0.18 is much easier to download than to compile
Release v0.0.18, published September 11, provides Linux archives, AppImages, Debian and RPM packages, Apple Silicon macOS bundles, Windows installers, and container images. Checksums accompany the assets. That distribution work changes the practical recommendation: a curious user should start with a prebuilt package, while source compilation is better left to contributors who need the current tree or an unsupported setup. The packaged route avoids our 900-second build problem, though it does not remove runtime compatibility gaps.
Source builders have several platform branches to understand. The pinned Rust toolchain is only the start. GStreamer enables video, WPE WebKit supplies the Linux inline browser, and VA-API can provide hardware decoding. The Fedora and RHEL guide says their repositories do not supply the WPE WebKit dependency, so that browser feature needs external source or packages. Tests also expect a specific GNU Emacs reference on PATH, since a newer upstream can change shared Lisp output and create widespread comparison failures.
GPU rendering creates a hardware floor that GNU Emacs does not have
Issue 109 reports startup failing because no suitable GPU adapter was found on one Linux system. Issue 402 asks for a fallback on weak or absent graphics hardware after trouble under WSL. Windows issue 384 describes severe lag while selecting text with the mouse on v0.0.18. None of these reports proves that every machine on those platforms will fail. Together with the project's experimental platform labels, they show why hardware and driver testing belongs near the start of an evaluation.
The renderer also expands what compatibility means. Fonts, cursor placement, overlays, input routing, web views, codecs, and window systems all become part of the promise. Release v0.0.18 includes fixes for layout, font metrics, macOS Option chords, terminal linking, and inverse video. Those are signs of active engineering, and also a list of surfaces where a daily editor can feel wrong long before it crashes.
Twenty CI workflows show activity, while the 900-second caps show cost
GitHub recorded the last push on September 20 and listed 53 combined issues and pull requests. Our checkout contained 20 CI workflow files and a tests directory. Release v0.0.18 arrived 9 days before that push, and current issues were receiving maintainer responses. This is an active alpha rather than an abandoned experiment. The pace is useful for contributors, but it also means behavior can change quickly between a tagged package and main.
Use NEO Emacs beside GNU Emacs, with a copy of your configuration and a clear rollback path. Its Rust core and GPU frontend are substantial work, and the project documents its unfinished areas unusually well. The two 900-second timeouts are the decision point: this is a project to test and help shape, not an editor to make responsible for your whole working day yet.