"Neomacs: The JIT-Powered Evolution — Bridging the Elisp Legacy with a RustPython Core"

[dvctl]

Hi @eval-exec,

I’ve been following Neomacs closely, and I want to start by saying: you are building exactly what the text editor ecosystem desperately needs right now.

To give you some context on where I'm coming from: I’ve spent the last five years as a hardcore Neovim user and Data/System Analyst. Neovim is incredibly fast, but recently, I hit a hard ceiling with its interactive rendering capabilities. Terminal UIs simply cannot handle the kind of rich, 120fps GPU-accelerated and fluid UI manipulations I want in a modern workspace.

Looking for an alternative, I turned to GNU Emacs, and I immediately fell in love with its core philosophy: Extensibility & Unification of Human & Machine. The total malleability of the editor—the idea that it's an introspectable OS rather than just a text editor—is a masterpiece of software design. But then I hit the Emacs ceiling: the single-threaded Lisp architecture. One heavy computation freezes the entire UI.

That led me to Neomacs. By rewriting the core in Rust and utilizing GPU acceleration, you’ve completely solved the rendering and concurrency bottlenecks. You’ve fixed the engine.

But as I looked at the project, I realized there is a secondary bottleneck looming: Community and Ecosystem. For Neomacs to thrive, it needs the gravity of a massive plugin ecosystem. And the hard truth that must be acknowledged is that Elisp—despite its historical brilliance—is the true culprit for the lack of rapid community growth in both Emacs and Neomacs. This has also become the bottleneck for extensibility philosophy in 2026.

I spent the last few weeks in a deep internal debate about how to bring modern extensibility philosophy to Neomacs without sacrificing the Unification philosophy of Emacs.

The Solution: Interface DSL (Domain Specific Language)

My immediate instinct was: What if Neomacs can be configured by the most popular language in the entire programming community? Based on this view, I started exploring alternatives. JavaScript/TypeScript and Python were the best options based on my analysis. Out of those, Python is the clear winner because of specific language technicalities. In short: the marriage between Rust and Python was probably decided in heaven.

My first thought: Lazy Evaluation

I thought this would be an absolute breakthrough. Applying Lazy Evaluation to an editor's architecture would be a paradigm shift. I thought, I am not just suggesting a new language; this would be a completely new way to think about how a text editor handles state and events.

Eager Execution is the culprit (the Old Way). If Neomacs uses Python eagerly (like Neovim uses Lua or Emacs uses Elisp), every time a user presses a key or saves a file, the Rust core would have to wake up the Python interpreter, cross the FFI boundary, run the Python function, and wait for the result. The problem: crossing that boundary thousands of times a second is slow. The Python GIL (Global Interpreter Lock) becomes a bottleneck.

In the Lazy Evaluation approach, Python does zero data processing. It just builds a blueprint and hands it to Rust. Rust then optimizes the blueprint, compiles it into native Rust, and executes it at Rust's speed. At startup, the Python config runs, but it doesn't execute editor commands. Instead, it builds a config blueprint (a graph of keybindings, hooks, and UI states). Python passes this plan to the Rust core via PyO3 and says, "Here is how the editor should behave. I'm going to sleep now." Rust compiles that plan into pure, native Rust. When you type, save, or render the screen, Python is completely out of the loop. The Rust core is executing the plan at 120fps. "Hot-swappable expressions" can be implemented to mimic the live configurability that arises by adopting Python with a lazy evaluation architecture. Crashes due to misconfiguration in the interface language can be completely handled or resolved in the Rust core. It solves the biggest counter-argument: "Python is too slow to run on every keystroke."

When I closely inspected the Python lazy evaluation architecture, this thought struck: What about live execution? The soul of Emacs is image-based persistence and eval-defun. Mimicking live configurability through hot-swappable expressions means no true live execution. By suggesting a Python-based lazy evaluation architecture, I realized I was killing the soul: the Unification of Human & Machine philosophy.

My second idea: Why not write a Python-to-Elisp compiler? (Pylisp)

Pylisp: A declarative DSL, used strictly for editor configuration and UI manipulation, leveraging modern, method-chaining syntax to construct Elisp expressions. Pylisp would allow users to configure Neomacs using clean, Pythonic expressions. But looking at the AST, I realized it's a trap. Python's lexical scoping clashes horribly with Elisp's dynamic history. Furthermore, mapping Python's single-dispatch OOP to Elisp's EIEIO multiple-dispatch system would generate bloated, unreadable Lisp code.

Even though this would be a nightmare to implement, and Pylisp would be an abstract layer on an abstract layer (Elisp) on another abstract layer (Rust), I thought: what's wrong with throwing a little more RAM and CPU at the problem? This doesn't kill the soul.

However, something felt off. I sounded more like a "Javascriptian" than an Analyst. Closer examination revealed that, in the name of suggesting a new language, I would be suggesting the community build an ecosystem not around Python the language, but around a Python package. This convinced me I was entering "JavaScript land" for sure.

The internal debate haunted me: Is the trade-off of philosophy worth it to onboard the Python community and gain access to the Python ecosystem? I came to the conclusion that we can't just "bolt Python onto Emacs" and call it Neomacs. We need an architecture that respects the Lisp Machine legacy while opening the floodgates to the Python ecosystem.

Further exploration suggested no other popular language can come close to Elisp. At this point I was frustrated, thinking there would only be trade-offs, and decided—with the intention to minimize those trade-offs—to examine the Emacs architecture one last time.

The examination gave me a clean picture of what Emacs is: it is an Elisp interpreter. This gave me the hope I was desperate for, because Python is also an interpreted language, albeit a slow one.

The rustpython Interpreter

Because of my data analytics background, I had already dealt with the slow Python interpreter by using numba.njit(). Further exploration led me to the solution: a Rust crate called rustpython which supports JIT out of the box. This was the "eureka moment" for me. The Elisp interpreter was the soul of Emacs; a rustpython interpreter can be the soul of Neomacs. And probably a better one, too. My gut intuition is that a new rustpython interpreter with a modern architecture will be faster or at least at par with the Elisp interpreter.

Syntax Readability (The Pseudocode Effect): Configuration files should be declarative and easy to read. Lisp is deeply nested (the "sea of parentheses"). JavaScript is heavy on brackets and callbacks. Python forces whitespace indentation. A 1000-line Python configuration file fundamentally reads like structured pseudocode. It is cleaner to parse visually.

If we compare Python against Lua (Neovim), JavaScript (VS Codium), or Elisp (Emacs), Python’s Standard Library has pathlib, subprocess, json, urllib, sqlite3, async, and threading built right in. A plugin developer can write a complex, OS-level integrated plugin without needing to go through the hassle of installing a single external dependency. Python provides access to world-class tooling and gradual typing. Editor configurations get huge and complex. Writing thousands of lines of untyped Elisp or Lua inevitably leads to runtime errors that only trigger when you hit a specific key combination. Python supports type hints. The Neomacs Rust core can generate Python stub files (.pyi). When a user is writing their config, their LSP will give them perfect autocomplete, hover documentation, and compile-time error checking for the editor's API. We get a mature, industrial-grade development experience just for configuring the editor.

**Introduction of a Rust-based, uv-inspired package manager: nemx**

When I say "uv," I am also referring to Cargo because uv is already inspired by Cargo. nemx doesn't just install Rust crates or Python packages; it fundamentally changes how developers interact with their environment. Neovim uses lazy.nvim, which is just cloning git repos. If a plugin needs a system dependency, we have to use middleman tools like Mason.nvim or install them via a system-level package manager. VS Code hides everything behind an opaque marketplace. Right now, sharing an Emacs or Neovim config is a nightmare. Even if you share your init.el or init.lua, it causes silent breakages for the person copying it due to environment mismatches.

nemx introduces strict, hash-verified lockfiles. Our entire editor configuration—including the exact commit of every plugin, the exact version of the rustpython interpreter, and the exact version of the Rust core—will be locked in a neomacs.lock file. This empowers the user to share their config with anyone on any machine. They run nemx sync, and they get a 100% byte-for-byte identical editor environment in seconds. "It works on my machine" could be permanently solved for text editors. This will also be our line of defense for the "dependency hell" that Python can bring.

Above all, no sacrifice on philosophy

I acknowledge the "Ecosystem Bankruptcy." Swapping Elisp means sacrificing 40 years of highly specialized Emacs packages; we lose Magit, Org-mode, etc. I think it is time to take the "Human & Machine Unification" philosophy to another level. We shouldn't force users to write raw Elisp, or only Python. In 1976, the "Machine" was a local CPU; now in 2026, the Machines are local and remote. As I said earlier, Neomacs should support all popular and interpretable languages.

I believe we should build a foundation for the next generation with the help of Rust. If we are trying to bootstrap a brand-new editor in the name of performance, in the era of cloud computing, we are fighting a war for a developer's free time. I believe there should be no entry fee (language barrier) for adopting Neomacs.

This architecture doesn't betray the Emacs philosophy; it evolves it. This is the bet I am making: Rust and Python communities are notorious for rewriting entire domains they can access at their respective scopes.

No priority collision, @eval-exec. The promise you made to Neomacs—complete reverse compatibility—stands. We will implement a Rust-based Elisp interpreter faster and together with a bigger community.

Let me know what you think of this proposal for Neomacs.

[rirze]

I'm not @eval-exec, but I've thought long and hard about this as well. I don't think Python is the right choice here. I've used Python for a long time and my greivances with Python always converge to the same fundamental problem: Python is not Lisp-y enough.

For a new editor, I think keeping elisp is ok. What could be better is to support SBCL or some other Common Lisp variant. I personally think that would propel development in a good way for the ecosystem. We don't necessary have to embed a "popular" language as the scripting language here. Having a small barrier in terms of language choice selects for good developers at the end of the day.

[dvctl]

I’ll be honest, I jumped into this project specifically because @eval-exec mentioned that 'Neo' is derived from Matrix. I’ve always felt a deep connection to that character and the idea of breaking a rigged system.

Regarding SBCL, I haven't explored it deeply, I do recognize that theoretically, it provides practically C-level performance. But if this project were simply a rebuild of legacy C code to add concurrency and modern GPU rendering, @eval-exec would have chosen Zig. Zig is objectively the more pragmatic tool for a direct performance rewrite. Even mainline GNU Emacs is already working on its own threading and GPU rendering.

The real reason for the Python/Rust architecture is deeper. In 1958, the Lisp philosophy was 'Code is Data, Data is Code.' It was a revolutionary idea for its time. But in 2026, the perception of 'Data' has fundamentally changed. Data is no longer just a symbolic list; it is a high-velocity, multi-dimensional mountain, to climb or carve this mountain the feveloper should have the opportunity to speak in his "Mother-tongue" with his machine.

If we look at the series, Neo’s tragedy was that he eventually settled for freeing only a few people because of lack of option. The system was too rigid. By suggesting we keep Lisp as a 'barrier' to 'select for good developers,' you’re asking us to stay in that same cycle of scarcity, limiting the power of a programmable environment to a 'chosen' few.

But I have to ask you: If Neo had seen an option to free everyone, what would he have done? even if that option had less then 1% sucess rate.

I belive, Neomacs is about giving that power to every developer, regardless of their 'background' or 'language religion.' its about building the exit for everyone."

[rirze]

Fair point, if we assume the philosophy of the scripting language should be wide adoption, then I agree, putting barriers is not ideal.

That being said, I don't think adopting Python itself is as big of an advantage as you think it is. I have some technical takes here:

• Take a look at https://qtile.org/, for example. It's notable but not necessarily as popular as it should be for using Python as its configuration language. Why is that?
• If Python (or any other language) is the scripting language, the interpreter for that language should be bundled with the editor. For example, Neovim ships with its Lua interpreter. I don't think we should be bundling Python executables with any editor fwiw. As a counterpoint, which you mentioned, there is https://github.com/RustPython/RustPython, which admittedly, is a subset and is far away from CPython stdlib compatibility. But if all we care about is a editor-specific scripting package, this is a fine choice.

Even if we choose a Lisp as the scripting language, we would have to include the Lisp compiler ideally. That could make my earlier choice of SBCL a little tricky as we would have to distribute it as a dynamic library (I think?, unsure about how this works in practice)

If all we care is about the whitespace-oriented ergonomics, I can suggest https://github.com/moonli-lang/moonli as an option. It could be used in addition to a Lisp syntax or exclusively as the scripting language. This would be very exciting as I've been eyeing this project personally.

There's also https://github.com/facebook/starlark-rust, which would be interesting since starlark cares a lot about hermeticity, which afaik, means it's very picky about side efffects (like io). It might make it a bad choice if the editor is not built with the same philosophy.

[dvctl]

I just came from my holidays; I need to first study SBCL to make an informed comment. Don't mind—I want to be sure about the architectural trade-offs before I weigh rustpython and SBCL.

but in the mean time @rirze your perception on qtile misses the mark because you aren't comparing it to its actual competitors.
When it comes to qtile, qtile is the best window manager and second most popular window manager in its tier.
despite the friction of constantly breaking after almost every major and some minor python update. (I tried to solve this by isolating qtile as per docs via pipx or uv but it seemed hacky considering arch-linux philosophy, currently i am dealing this problem via btrfs snapshots)

In the world of window managers there are 2 main catogories
1. Floating window managers
2. Tiling window managers

qtile lands in tile window managers. there also it lands in a very niche market which also induses more friction, "complete control over the window manager".
popular alternative is the AwesomeWM (lua) & Xmonad (haskell). (note how popularaity is comming down to language)
Most users treat a WM as a glorified app launcher, and for tweaking UI asthetics. As being an active qtile user from 6+ years, earlier i was using X11 and recently switched to wayland compositor. for me my workflow is a closed loop between window manager (qtile), terminal (foot), browser (qutebrowser).
on start-up my system pulls 830-860MB of RAM (including qtile, 1 foot terminal running btop), i am keeping my system minimal and applied zstd compression on RAM. if I start speaking on how I have integrated and planning to integrate my workflow around qutebrowser its never going to end.

let me share a small story.
Some where around mid-night; after a long coding session; due to my workflow being keyboard centric my 'pinky' was crying badly. I realized, I can use my webcam to track eyeballs and subtle head movements to autonomusly, seamlessly switch between workspace / windows / panes. At the point of this realization i thought it was a revolutionary idea and started to analyze it in the very morning. Couple of days later when i tested it; I realized it doesn't work properly due to lighting / reflection / refraction. I archived the project and moved on because I don't want my system to recive inputs which were not intended.

i love to automate anything that I feel is repitative. thats my persona; probably the reason why python became my "Mother-tongue". But that story, is not a 'success' story, nor about a revolutionary idea; And definetly not about promoting python using its best in class ML / AI infrastructure.

It was about an opportunity I had to play-around with my machine because the communication was in my "Mother-tongue"

Now if you see the number; i3 WM pulls roughly around 10-30MB of RAM, AwesomeWM pulls around 30-70MB of RAM, qtile pulls around 80-200MB of RAM, (on my system qtile consumes around 130-170MB.

Yes, I pay that RAM tax gladly. I sacrifice 'ease of use' for the 'freedom to tinkering my workflow.' Rather then settling for ctrl-c -> ctrl-v dotfiles. That is a user decision, and it must remain one."