[HN Gopher] Lem v2.0.0 - Common Lisp IDE with high expansibility
___________________________________________________________________
Lem v2.0.0 - Common Lisp IDE with high expansibility
Author : mepian
Score : 101 points
Date : 2023-05-22 13:05 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| whartung wrote:
| 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.
| dang wrote:
| 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.
| dang wrote:
| Related:
|
| _Lem: A Common Lisp editor /IDE with high expansibility_ -
| https://news.ycombinator.com/item?id=19407548 - March 2019 (77
| comments)
| xedrac wrote:
| 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.
| lobstrosity420 wrote:
| 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.
| Conscat wrote:
| 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.
| vindarel wrote:
| 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...
| akho wrote:
| 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.
| mepian wrote:
| What Emacs extension would you personally use for the
| compatibility validation?
| vindarel wrote:
| 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...)
| ShadowBanThis01 wrote:
| Thanks for the useful title!
| kirankp89 wrote:
| 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.
| 1equalsequals1 wrote:
| How does it compare with Portacle?
| medo-bear wrote:
| portacle is an emacs based ide for common lisp
|
| lem is a common lisp ide for several languages
| tmtvl wrote:
| I wonder if Lem supports running in server+client configuration,
| that's probably my favourite Emacs feature.
| vindarel wrote:
| 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!
| BaculumMeumEst wrote:
| 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.
| LispSporks22 wrote:
| Heh looking at the source someone went all out on SBCL
| internals
| Nezteb wrote:
| Same! https://github.com/lem-project/lem/issues/627
| jaccarmac wrote:
| 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
___________________________________________________________________
(page generated 2023-05-22 23:01 UTC)