3 ms·
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.
by cmrdporcupine 1mo 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 1mo agoIt’s a better lisp, too. Elisp really sucks and is my least favourite part of emacs, which I use daily.
- cmrdporcupine 1mo agoI'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 1mo agoI 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 1mo agoI'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 26d agoCL 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.