4 ms·

Seems fully vibe coded :(

by smy20011 20d ago

pkghost 20d ago
"Emacs, rewritten in Rust — unleashed on the GPU, fixing what 40 years of C never could."
- bitwize 20d ago
  "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."
convolvatron 20d ago
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.
- cmrdporcupine 20d ago
  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.
  - stackghost 20d ago
    It’s a better lisp, too. Elisp really sucks and is my least favourite part of emacs, which I use daily.
    - cmrdporcupine 18d ago
      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.
  - whois 20d ago
    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.
  - hollerith 20d ago
    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.)
  - iLemming 13d ago
    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.
quasarj 20d ago
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.
- otabdeveloper4 20d ago
  > claims to be Yes, quite the smoking gun of a load-bearing phrase.
  - quasarj 20d ago
    Sure, but you can check yourself if you're worried about it.
EgregiousCube 20d ago
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!
- timacles 20d ago
  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
  - rayiner 20d ago
    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/neomacs-display-runtime/src 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.c 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.)
    - bitwize 19d ago
      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.

Seems fully vibe coded :(

pkghost 20d ago

"Emacs, rewritten in Rust — unleashed on the GPU, fixing what 40 years of C never could."

bitwize 20d ago
"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."

convolvatron 20d ago

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.

cmrdporcupine 20d ago
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.
- stackghost 20d ago
  It’s a better lisp, too. Elisp really sucks and is my least favourite part of emacs, which I use daily.
  - cmrdporcupine 18d ago
    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.
- whois 20d ago
  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.
- hollerith 20d ago
  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.)
- iLemming 13d ago
  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.

quasarj 20d ago

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.

otabdeveloper4 20d ago
> claims to be Yes, quite the smoking gun of a load-bearing phrase.
- quasarj 20d ago
  Sure, but you can check yourself if you're worried about it.

EgregiousCube 20d ago

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!

timacles 20d ago
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
- rayiner 20d ago
  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/neomacs-display-runtime/src 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.c 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.)
  - bitwize 19d ago
    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.