NEO Emacs – GPU-Accelerated Emacs Powered by Rust
neomacs.org
neomacs.org
I'm afraid that 100% compatibility may be very often at odds with multi-threaded elisp. So much in Emacs depends on global state :-/
> ~95%, closing the last gaps
If coding with LLMs taught me anything, it’s that this last 5% can be “load-bearing”.
One thing you could imagine is doing some kind of mvcc system so that if two tasks don’t interfere with each other, they can execute in parallel (and if not, abort one and rerun it sequentially).
But maybe that still doesn’t work because all the things that should be run concurrently are using the same buffer and doing manipulations of it. You could imagine trying to make save-excursion introduce an opportunity for parallelism: split into a separate thread for the body as that thread is no longer modifying global cursor state (in some sense). Don’t let two threads write to the same buffer for concurrent tasks that should appear sequential, but do allow them to read in parallel (surely most things are merely reading).
However I’m not sure you actually need all that cleverness. I think you could have some combination of:
- tools to make multithreaded elisp more viable
- manual attention to improve major sources of slowness by introducing parallelism (eg font-lock, rendering, autocomplete, indentation). A stupid thing could be precomputing (in the background) what would happen in the user pressed RET (or TAB) and then being able to execute it sooner if they press that key.
But also suspicious of anything this AI generated which touts rust like this.
That happened before with Xemacs. I saw somewhere Xemacs development has been restarted.
so I don't think one can achieve that by maintaining 100% compatibility. a much smaller base system build with better semantics that was notionally compatible would be something I would be really excited to contribute to.
IMHO there should ideally be a minimal shared transactional blackboard space that processes can coordinate in and then each buffer should be its own isolated process/thread -- like a chromium tab.
Yes, quite the smoking gun of a load-bearing phrase.
The moment random bugs start hitting and fixing the bugs starts breaking other things, no one is going to want to contribute.
Its all going to devolve into a slop fest that takes more and more effort to make incremental progress
Emacs, meanwhile, has a 50,000 line file that contains its display and redisplay logic: https://github.com/emacs-mirror/emacs/blob/master/src/xdisp..... (It's actually a pretty readable well-commented file all things considered, but famously difficult to hack on.)
I think I'd rather have that than the state of the art in "modern" TUIs, which is to do the opposite and treat the terminal as a special case of React canvas, redrawing the whole damn thing every time there is a keystroke or other action by you or the program. You can see Claude Code redraw itself all the time; it's maddening. And the program would absolutely be unusable on, say, a 9600bps connection, whereas Emacs could still get by on that. This is from the company that retains the best and brightest programmers, and will have self-improving runaway genius AI by Christmas, for realsies this time.
maybe it targets net new users?
This landing page made sure I lost interest in this attempt.
JFC, who wants animations in their editor?
Also, I set prefers reduced motion on my browser. Pages that are filled with useless animations in spite of my preference tells me the dev is either incompetent as they cannot handle basic accessibility or an asshole because they just don't care.
Richard Stallman prefers to call AI "Pretend Intelligence".
https://github.com/SimHacker/moollm/blob/main/designs/PRETEN...
Richard Stallman proposes the term Pretend Intelligence (PI) for what the industry calls “AI”: systems that pretend to be intelligent and are marketed as worthy of trust. He uses it to push back on hype that asks people to trust these systems with their lives and control.
From his January 2026 talk at Georgia Tech:
https://youtu.be/YDxPJs1EPS4?t=641
"So I've come up with the term Pretend Intelligence. We could call it PI. And if we start saying this more often, we might help overcome this marketing hype campaign that wants people to trust those systems, and trust their lives and all their activities to the control of those systems and the big companies that develop and control them." — Richard Stallman, Georgia Tech, 2026-01-23. Source: YouTube (full talk) — "Dr. Richard Stallman @ Georgia Tech - 01-23-2026," Alex Jenkins, CC BY-ND 4.0; transcript in video description.
Jokes aside, this is exactly the kind of mad-science evolution Emacs needs, rather than being hard-blocked by 1980s terminal-era C code.
I'm curious how much of this project is done by AI? PS: kudos for doing it, I will definitely support it!
Not that the README is any better. It's just a long string of Claudisms. Fuck.
"Don't you ever get bored of pointing out that everything is AI slop?" Yes. I am very bored of pointing this out. I'll let you know when getting bored of it fixes the problem. I'm sorry if you think slop that will likely be unmaintained in a month and can be done even better by next month's model releases anyways is worth taking up a massive chunk of the HN frontpage forever, but I just don't agree.
They still don't.
> Now that the README actually describes what the project is all about you don't read it because "it's AI slop".
Going from no documentation to very bad documentation is closer to a lateral move.
I do think repos with only AI slop docs should probably just delete them. They are absolutely worse than nothing in most cases.
I'm pretty jaded these days, so I decided to compile this and give it a go.
I am actually a little surprised.
So far, all of my configuration and packages have just worked out of the box. Eglot (LSP), Treesitter, evil, themes configuration and all my custom elisp and just kind of work. Brownie ponits there.
Unfortunately, the developer has chosen to; for lack of a better phrase; gone batshit insane with cursor and window animations. The homepage looks nothing like what's OOTB either, so quite misleading to be honest.
Otherwise, pretty decent job, feels smooth and will check in another year.
e-lisp code is massive!
I feel like emacs could be way better if e-lisp was typed but I write Rust for a living and Haskell/Lean for fun so maybe I'm biased
That's just factually untrue. Emacs core is not obviously buggier than, let's say, VSCode, which has tens of thousands of open issues and is written in Typescript. What differs is visibility. Emacs throws a backtrace in your face; VSCode swallows extension errors into a log nobody reads. And every Emacs user runs a unique build with like 350 packages nobody tested together; try to even start VSCode with half that number of plugins.
The bugs that actually hurt in Emacs are state bugs, not type bugs. Two packages advise the same function. A buffer-local variable is set in one mode and read in another. Dynamic binding leaks. None of that is a type error in the Haskell sense.
The dynamism is the product, not an accident. Redefining any function at runtime, advising anything, inspecting live state - that is why people use Emacs instead of an editor with a plugin API. Strong static types plus separate compilation cut against late binding everywhere.
You're not "biased", you just seem to be unfamiliar with the type dynamism in Lisp systems. Dynamic types are not equally bad everywhere; don't take what you know about Python and apply it the same way to things built in, e.g., Clojure.
I can see moving some core functionality currently implemented in elisp into Rust (or whatever typed intermediate implementation language). But there is a cost to having stuff in the core - user can't step into C functions with the elisp debugger.
This isn't the excuse - just try Emacs! I've gone through periods where I really wanted to level-up my $EDITOR-fu, and just jumping in is what I did. Compared to so many other decisions, this is such a low-barrier, low-cost decision, there's no reason to not just do it. If it's stalling your development speed, jump back to vi or VSCode, or whatever. Don't want to stick with Emacs? Uninstall and forget it was ever there.
For my editor explorations (vi, emacs, ex), I was strict with myself and used $EDITOR exclusively for 4 or 8 weeks (I forget which) - which sometimes just turned into years.
I'm not deep into Emacs culture these days, but I'm hard-pressed to understand why one wouldn't just go canonical GNU Emacs rather than some fresh "revolutionary" Emacs - you'll have your mind blown regardless, without the potential bugs and lack-of-history/community which come with some new-hotness interpretation of a standard that is already fit-for-purpose.
After continuous iterations of development，when neomacs is mature, I'll invite you to try neomacs.
I've also considered the possibility of a Rust rewrite of emacs, but after doing some more digging it seems like it may not be worth the effort. The remacs project seems to have been abandoned. I think they hit diminishing returns
Moreover, this ready like AI slop
But my friends test launch doomemacs for neomacs on Linux, it can works, but still have some incomplete places。
I mean gnu-emacs is already quite snappy in Wayland mode.
This is trying to be compatible with GNU Emacs.
That depends on what you mean by compatibility.
Keybindings and conventions and the like are basically the same.
I'm not actually convinced at this point on the value of a lot of the extant elisp out there.
Emacs Lisp...
> I'm not actually convinced at this point on the value of a lot of the extant elisp out there.
I agree but lots of people probably don't.
I have updated the watch demo button link, redirect it to my youtube website link。
I don't see any notes in the README about alternative scripting engines, elisp was always the main thing that turned me off from emacs. Does anybody know if they plan to add something like Lua?