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.)

That's descended from its terminal escape-sequence optimizer, the bit of code that transforms one screen state into another screen state in the least number of terminal commands possible. (That display code was later updated to support graphical output like X11 by treating it as sort of a special case of a terminal.)

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.

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.

Sure, but you can check yourself if you're worried about it.

"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.

I'm not a Lisp connoisseur, but the parts of GNU Emacs that bothers me are more all a) the C-based glue... single-threaded single process monolith b) giant ball of mutable state that seems to let anything step on anything else and break things in confusing ways.

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.

I've never gotten lem to display anything readable in a browser tab over 2 tries separated by 6 months. (I didn't try the terminal front end.)

CL is really not the answer. In fact, most Lisps probably can't beat Elisp for the simple reason that majority of Lisp dialects are very data-oriented, while Elisp is specifically text-oriented and that's not the property of the language but the runtime - implicit current buffer, an implicit point, global match data, etc. You can't simply replace forty years of packages, where every single one of them assumes the exact Emacs runtime. Lem's problem (or any Emacs alternative) is that it has to be much better to justify migration, and nothing is much better than Emacs at being Emacs.