Most state is buffer-local rather than global. Note also that there is already some amount of multi-threading in elisp.
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.
Interesting interesting. I'm huge into Emacs and have felt like Emacs has needed a Neovim sort of moment for a while now. A lot of the modern features you'd expect out of an IDE are bad and slow in Emacs rn due to threading and pretty core issues to Emacs (so I cope and say I don't need autocomplete).
But also suspicious of anything this AI generated which touts rust like this.
Appears to be further along than anybody's ever gotten with a multi-threaded emacs port. If that's what vibe coding gets us, three cheers for vibe coding!
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 no longer see an issue with that, assuming it can be tested to prove it works. In this case, it's being tested (or well, claims to be) against real Emacs, which should be all that's needed.
"Now I see the whole picture. The Emacs Lisp interpreter lock bungs no cake. The buffer-pruning-time crenellation is a glaze which conflicts with the cthulhu fhtagn peripatetic saxophone layer; the result is not cromulent. Three pounds of VAX. This has now been fixed."
general issues aside, for me one of the issues with emacs is that for historical reasons there is a cut between elisp and C that's really high up and pretty ragged. ideally a large composable lisp project like emacs would have a very accessible continuum between the surface and the underpinnings.
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.
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.
It's ironic that a community that uses a program originally developed at the MIT AI Lab, extensible in the traditional programming language of AI, would hate AI.
Richard Stallman prefers to call AI "Pretend Intelligence".
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.
"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.
I've gone from being blown away by what LLMs could do with web design (I mean, it's impressive, especially what it does purely without vision...) to wishing it couldn't. Everything has become "same"y in a way that is hard to describe, kinda like AI generated images. Panda riding a unicorn? Impressive the first time. 1000 uncanny piss filter Pixar images later, you are begging for mediocrity to come back.
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.
The README is actually much better. Before AI it was three sentences or a placeholder template and you were complaining how nobody writes decent documentation. Now that the README actually describes what the project is all about you don't read it because "it's AI slop".
> I've wanted an excuse to try out emacs in the first place[...]
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.
With neovim's cult following I figured it was only a matter of time before somebody made a similar rewrite for Emacs, even if it does smell of vibe-coding based on the README.
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?
Emacs-ng embeds JavaScript or TypeScript or something and a web engine for UI. But then I really don't see the point. You're just about halfway to Visual Studio Code, so why not just use that?
> Aiming for modern design, multi-threaded Elisp, 10x performance and 100% Emacs compatibility.
I'm afraid that 100% compatibility may be very often at odds with multi-threaded elisp. So much in Emacs depends on global state :-/
Current status of the compatibility is[1]:
> ~95%, closing the last gaps
If coding with LLMs taught me anything, it’s that this last 5% can be “load-bearing”.
[1]: https://github.com/eval-exec/neomacs#status
That's where all the smoking guns are buried.
That's why I use a belt and suspenders to pick them up.
Most state is buffer-local rather than global. Note also that there is already some amount of multi-threading in elisp.
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.
Interesting interesting. I'm huge into Emacs and have felt like Emacs has needed a Neovim sort of moment for a while now. A lot of the modern features you'd expect out of an IDE are bad and slow in Emacs rn due to threading and pretty core issues to Emacs (so I cope and say I don't need autocomplete).
But also suspicious of anything this AI generated which touts rust like this.
>I'm huge into Emacs and have felt like Emacs has needed a Neovim sort of moment
That happened before with Xemacs. I saw somewhere Xemacs development has been restarted.
Seems fully vibe coded :(
Appears to be further along than anybody's ever gotten with a multi-threaded emacs port. If that's what vibe coding gets us, three cheers for vibe coding!
I just cant imagine anything vibe coded being maintained for more than a few months.
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
Have you looked at the code before rendering judgment? It seems pretty readable and well-structured: https://github.com/eval-exec/neomacs/tree/main/crates/neomac...
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.)
human code gets that way too, it just takes longer
I no longer see an issue with that, assuming it can be tested to prove it works. In this case, it's being tested (or well, claims to be) against real Emacs, which should be all that's needed.
> claims to be
Yes, quite the smoking gun of a load-bearing phrase.
"Emacs, rewritten in Rust — unleashed on the GPU, fixing what 40 years of C never could."
"Now I see the whole picture. The Emacs Lisp interpreter lock bungs no cake. The buffer-pruning-time crenellation is a glaze which conflicts with the cthulhu fhtagn peripatetic saxophone layer; the result is not cromulent. Three pounds of VAX. This has now been fixed."
general issues aside, for me one of the issues with emacs is that for historical reasons there is a cut between elisp and C that's really high up and pretty ragged. ideally a large composable lisp project like emacs would have a very accessible continuum between the surface and the underpinnings.
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.
Yeah, that's "lem" really. Though in that case it's Lisp all the way down apart from the native bits of the rendering layers.
I keep meaning to check out Lem. It just pains me having to get my setup set up all over again. But, long term Lem is probably the move.
It’s a better lisp, too. Elisp really sucks and is my least favourite part of emacs, which I use daily.
the webpage fills vibecoded in the worst way tbh; i don't think that's attractive to the current gen of emacs users
maybe it targets net new users?
I'm interested in a multi threaded emacs.
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.
It's ironic that a community that uses a program originally developed at the MIT AI Lab, extensible in the traditional programming language of AI, would hate AI.
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.
Lost me with broken "Watch Demo" button
I've gone from being blown away by what LLMs could do with web design (I mean, it's impressive, especially what it does purely without vision...) to wishing it couldn't. Everything has become "same"y in a way that is hard to describe, kinda like AI generated images. Panda riding a unicorn? Impressive the first time. 1000 uncanny piss filter Pixar images later, you are begging for mediocrity to come back.
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.
I feel like we need some version of "increase the temperature" that works at a macro scale instead of on individual tokens.
The README is actually much better. Before AI it was three sentences or a placeholder template and you were complaining how nobody writes decent documentation. Now that the README actually describes what the project is all about you don't read it because "it's AI slop".
The watch demo button doesn't work for me
Oh that looks so pretty! I've wanted an excuse to try out emacs in the first place, and this could be it!
> I've wanted an excuse to try out emacs in the first place[...]
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.
Please just try out traditional Emacs, I'm not sure this will paint a fair picture.
Does the "Watch Demo" button do anything?
It's hard to take this seriously when it has wonky Claude website design. Rewriting emacs in Rust also feels like a nonsensical task.
It's not nonsensical, but if you were writing emacs in rust, you hopefully would use a typed language instead of elisp
Why? There's no point having a typed config/scripting language...
Emacs written in rust.
Watch demo button on the website doesn't work.
I mean gnu-emacs is already quite snappy in Wayland mode.
the "performance" link at the top also doesn't lead anywhere...
Why not... Lem?
Lem's focus seems to be on being an "emacs" in and for Common Lisp. Lem throws away any attempts at compatibility with GNU Emacs.
This is trying to be compatible with GNU Emacs.
With neovim's cult following I figured it was only a matter of time before somebody made a similar rewrite for Emacs, even if it does smell of vibe-coding based on the README.
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?
Emacs-ng embeds JavaScript or TypeScript or something and a web engine for UI. But then I really don't see the point. You're just about halfway to Visual Studio Code, so why not just use that?