Some time ago I grabbed the source code and noticed some vi binding issues. So I opened up the lem source code with lem itself and went about fixing one of the issues. It was a bit like performing brain surgery on myself. But it was really cool to see my changes in action immediately. Of course it wasn't hard to break my ability to edit completely, but it was a really neat way to iterate on an editor.
Just giving it a glance, I hope that if someone might be interested in Common Lisp, they should take a look at this source base and how it isn't really that scary, or different, from most any other code base.
It's quite readable, doesn't go off in the weeds with all those fears that CAN be done in CL. Just a few macros, which seem straightforward. Some CLOS classes.
Looks cool but the install instructions fail on my mac m1:
Aborted during step [1/3].
Unhandled UIOP/LISP-BUILD:COMPILE-FILE-ERROR in thread #
<SB-THREAD:THREAD "main thread" RUNNING
{7005274C13}>:
COMPILE-FILE-ERROR while
compiling #<CL-SOURCE-FILE "log4cl" "src" "naming-sbcl">
I'm now 0/5 on the last interesting common lisp programs/libs I've tried to load on this machine: cl-cffi-gtk, cl-sdl2, nyxt, mgl, and now lem. CL is not m1-friendly it seems.
Not sure if either of the linked issues below are from you, but it looks like the referenced file in Log4CL references internal SBCL symbols which are liable to change in versions. Last I heard, the M1 build of SBCL was a bit unique, so it might be worth opening an issue there. The sharplispers fork is the maintained one, I believe.
This looks great and having access to SDL2 has my hacker brain tingling. I have been hacking on a grid based productivity tool similar to org mode. I’m wondering if I can use Lem as the frontend for it instead of all the complicated nonsense I’m attempting now.
A high performance asynchronous alternative to Emacs sounds great, but it feels like the Elisp ecosystem is so massive that I can't imagine everything I care about being ported to Lem. Maybe I could stab at a few myself if I was determined to use it, but I wonder if a high degree of Elisp compatibility macros could help adoption.
I don’t know. The problem does look big, but we’ve all recently seen the Neovim community rewrite a similarly-scoped ecosystem in Lua in couple of years. Logseq seems like a rewrite of a large part of Org, and was also doable.
Also, tons of Emacs packages should not exist, and are only there because core is slow-moving and old. Zillion completion frameworks, modal editing modes used by three guys, &c.
Deep issues (async/multi-thread, performance, display, namespaces) seem hard to solve without a breaking change.
As someone who recently started learning lisp, this is great and the simplest install and setup of any lisp environment I have tried, wish I had found it a month ago. Only issue I had was the log4cl issue many seem to have but cloning the repo for log4cl solved that and all is well.
I didn't try but I suppose so, since in any CL program we can start a Swank server (backend of Slime) and connect to the running program. Good question!
Lem also works for Python, Rust, HTML [and more](https://github.com/lem-project/lem/tree/master/modes), it has a built-in LSP server, a vi layer, a directory mode…
It has a very good CL REPL, with an interactive debugger. Call it from Lem: M-x start-lisp-repl or directly from the CLI:
Also, more editors for CL (Jetbrains (new!), VSCode, Sublime, Atom/Pulsar, Vim…) https://lispcookbook.github.io/cl-cookbook/editor-support.ht...)