Has anyone used this? I was just thinking the other day that it would be nice to have an emacs-like editor written in such a way that it made performance and parallelism easier, especially around multithreading.<p>A real killer feature would be some kind of emacs-lisp compatibility layer so that you could load existing third-party emacs modules, but I imagine the complexity of that is so off the charts that it would be unrealistic.<p>Has anyone successfully packaged it for NixOS? I see this aborted attempt here: <a href="https://github.com/NixOS/nixpkgs/issues/250777">https://github.com/NixOS/nixpkgs/issues/250777</a> (linked from <a href="https://github.com/lem-project/lem/issues/890">https://github.com/lem-project/lem/issues/890</a>). If not, I guess I might just try patching the binaries rather than trying to build it from scratch, since I don't have any experience building common lisp projects in nix.
I'm watching it with attention but some stuff is concerning:<p>* Some binaries in the source tree like <a href="https://github.com/lem-project/lem/tree/main/extensions/terminal/lib">https://github.com/lem-project/lem/tree/main/extensions/term...</a><p>* Commit messages aren't really descriptive.<p>* PRs and issues lingering in the void.<p>* Working around the strange inferior process thing (cf <a href="https://github.com/lem-project/lem/issues/1076">https://github.com/lem-project/lem/issues/1076</a>) that could be replaced by uiop:launch-program when a tty/pty isn't needed; still no LSP in c-mode, and forget C++, obviously.<p>Well, let's be honest, it's very interesting but still a one-man effort, as far as the core editor goes, so these are pretty normal.
I'm very excited, emacs does get a bit janky at times, especially with many packages installed. This is far more batteries included and it not having a "redisplay.c" is a huuuge plus in my opinion. I'll try to use it and see how far I can get, if LSP works it's enough to do basic work + a magit alternative also already exists.
I took a look at it since I'm learning cl. lem doesn't appear to have a concept of emacs frames? I have all the HiDPI display area that I could ever want, and an fvwm-based emacs dev configuration evolved over 25 years. The feature mandatory to my (and only mine) dev happiness is to have overlapping emacs frames with the mouse used to rollover often barely visible frames to autofocus them when needed. My memory cache of <i>which</i> frames are important <i>when</i> is helped by where I place the frames on the screen. This is optimally efficient for me, it's a pleasure to work in.<p>Although I dearly loved terminal turbo pascal/c, I really detest tiling only window managers/apps.<p>I just built lem-sdl2 from git and I'm poking around the "Workspaces" "docs" and I'm not seeing what I need. Am I missing something? I'd say, "oh boy, so cool" if I am. If I am not missing something, darn.<p>[edit: make it clear I built the sdl2 variant on debian testing]
It's odd to describe this as "emacs-like". It <i>is</i> an emacs. While most people mean "GNU Emacs" (or in the past XEmacs) when talking about emacs, emacs is really a family of editors, with many variations over the years. Including ones written purely in lisp, like lem is.
E. Naggum published quite a few pertinent ideas and code: <a href="https://www.emacswiki.org/emacs/ErikNaggum" rel="nofollow">https://www.emacswiki.org/emacs/ErikNaggum</a>