Item — HN Reader

Wondering if the Lem project is “accepted” (or worth a test drive) by the Emacs community. I’m a long time Emacs user, occasionally leaving but always returning. Lately, Lem has my attention. https://github.com/lem-project/lem

For those not familiar, Lem is very approximately an Emacs, natively written and extendable in Common Lisp, multiplatform, NCurses & SDL2, etc. LSP. And fast.

4 comments

I remember that last year's talk on Emacsen included Lem and it was well-received. https://emacsconf.org/2023/talks/emacsen/ I hope Lem continues to grow!

Lem is really great. I hope it keeps gaining mind share because it's superior to emacs in a lot of key ways.

What is better, from your experience?

I'm a happy Emacs user, but think having more options is great, and I've delved into some Common Lisp and certainly am eager to learn more. So I'm thrilled to see Lem continue to be developed.

Emacs is "better" only because it has more features at present, and is somewhat more mature.

But emacs remains replete with bugs, the performance leaves a great deal to be desired, the UI locks up if you update your packages because the whole thing is single-threaded, and emacs lisp (the language) quite frankly sucks, a lot.

Lem is not very mature and has a lot of sharp edges but already in this state I can see that it will eclipse emacs if it continues its current trajectory.

Agree with the other responder, largely. I've been bothered a few times by Emacs locking up, but never enough to be actually upset about it. Bugs, I don't see it, it is very very solid for me, I can't remember the last time something didn't work as expected. Hmmm.

Still very Lem-curious, though!

Oh come on. Emacs is not that buggy. For a piece of software that's been developed for over forty years it's quite surprisingly stable. Most of the "bugs" I see are due to some tighter integration between different packages - someone upstream would change something that inadvertently breaks things somewhere else. It doesn't happen that often.

Also, Elisp isn't really that bad. Well, sure, Common Lisp of course is a lot nicer language, and of course, not having any good concurrency story doesn't add any points, still, Elisp isn't so horrendous.

That being said, I do really hope Lem would get traction, and people start building plugins for it. Alas, realistically I'm not sure how feasible that would be. Replicating anything like Org-mode, with tons of extensions may take many years. Lispers however are known for their tenacity and ingenuity, who knows, maybe it wouldn't take too long.

Concurrency is very important these days though. Yet it is an extremely hard to solve problem in Emacs, due to tons of mutable global state, ingrained for decades, very hard to convert to something that works OK when running concurrently.

I use Emacs every day. It is my editor and in general tool of choice. However, the longer the concurrency story is not improved, the more advantages do other projects accumulate, because this concurrency thing is part of everything. Even VSCode seems to be better at concurrency. What a shame.

I think the only way in Emacs to properly use multiple cores for speedup is to start external processes. Sometimes that is a natural thing to do. But one also needs to process the result of an external process. Say for example a huge git diff in a magit buffer. All that stuff needs to be rendered/fontified. Editor locks up. That's just really bad. And people discuss workarounds all the time, writing code with these limitations in mind, meaning, that this makes code more complex everywhere.

I tried it out twice now but it doesn't support multiple frames. So it's a terminal only sorta thing? Or maybe Wayland? Whatever, it doesn't support multiple decade proven workflows. Totally ok, but not superior.

Lem is a nice try, but the default theme is utterly disgusting and because it wasn't designed with themes in mind going with a sane theme is impossible (because some colours are hardcoded so they become impossible to see on a proper light background). The lack of an Emacs-like configuration UI and Emacs-like documentation is also unfortunate.

Latest release is of February. Has progress been made?

It is clear from the commit history that the project is active and work on it continues.

I’m running that February release as my daily driver on MacOS happily. Haven’t launched Emacs except by accident for a few weeks. I admit it’s an experiment but so far so good.

Lem always feels very responsive (threading or rendering architecture, I assume) and my meagre needs for Emacs keystrokes seem supported. One thing I’d love to see Lem support soon, though, is org-mode awareness.

I think that releasing is the run git tag, writing a ChangeLog from the previous version, and pushing to GitHub, but I don't think that this act has much meaning.

I think binary files that can be executed by just clicking on them are valuable, but they can be done independently of releases. It's very difficult to make them work on a machine other than your own using sbcl, so I haven't been able to do it continuously.

But when I think back on it, the act of releasing also shows that the software is still alive, so I want to release it

Sounds nice, how is the ecosystem of plugins/extensions compared to Emacs? Are there Debian packaging plans?