Lem v2.0.0 – Common Lisp IDE with high expansibility | Hacker News Reader

Lem v2.0.0 – Common Lisp IDE with high expansibility

github.com

129 pointsmepian22 comments

Awesome release!

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:

    lem --eval "(lem-lisp-mode:start-lisp-repl t)"

Also, more editors for CL (Jetbrains (new!), VSCode, Sublime, Atom/Pulsar, Vim…) https://lispcookbook.github.io/cl-cookbook/editor-support.ht...)

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.

That is the magic of EMacs. If Lem manages to capture that, and improve in other areas like performance - they might make something really special.

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.

But, really, it's just code.

Take a look at it.

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.

https://github.com/7max/log4cl/issues/41 https://github.com/sharplispers/log4cl/issues/45

Heh looking at the source someone went all out on SBCL internals

Same! https://github.com/lem-project/lem/issues/627

`ros install sbcl-bin/2.3.2` fixes the log4cl compile error issue

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.

Lem: A Common Lisp editor/IDE with high expansibility - https://news.ycombinator.com/item?id=19407548 - March 2019 (77 comments)

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.

What Emacs extension would you personally use for the compatibility validation?

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.

FWIW, here's an experiment that was able to run Emacs's calendar program in CL (not the buffers and gui stuff, only "pure" elisp).

https://sourceforge.net/p/clocc/hg/ci/default/tree/src/cllib...

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 wonder if Lem supports running in server+client configuration, that's probably my favourite Emacs feature.

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!

Thanks for the useful title!

How does it compare with Portacle?

portacle is an emacs based ide for common lisp

lem is a common lisp ide for several languages

Since it doesn't look like the project has been discussed on HN before, we switched the link from https://github.com/lem-project/lem/releases/tag/v2.0.0 to the project page.

Edit: oops, there was a thread in 2017 (see https://news.ycombinator.com/item?id=36035158) - but that's long enough ago that this switch is probably still good.

Reply on news.ycombinator.com