3 ms·

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 rag

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 12d 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 12d ago
  It’s a better lisp, too. Elisp really sucks and is my least favourite part of emacs, which I use daily.
  - cmrdporcupine 10d 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 12d 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 11d 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 5d 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.

cmrdporcupine 12d 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 12d ago
It’s a better lisp, too. Elisp really sucks and is my least favourite part of emacs, which I use daily.
- cmrdporcupine 10d 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 12d 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 11d 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 5d 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.