Lem: Emacs-like editor written in Common Lisp

https://lem-project.github.io/#

by amarsahinovic • 2 years ago

203 59 2 years ago

lem-project.github.io

mplanchard3• 2 years ago

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.

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.

Has anyone successfully packaged it for NixOS? I see this aborted attempt here: https://github.com/NixOS/nixpkgs/issues/250777 (linked from https://github.com/lem-project/lem/issues/890). 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.

okasaki• 2 years ago

Emacs is pretty snappy these days, what kind of performance problems are you seeing with it?

stackghost3• 2 years ago

I use emacs every day, with a minimal config, and would never describe it as snappy. The entire thing is single threaded so the UI locks up at the slightest provocation, like for example when firing network requests whilst packages are updating.

mmmore2• 2 years ago

I use spacemacs and have problems with the editor locking up when some extension does some a lot of work.

There's also a strange bug (at least I think it's a bug and not a feature that I don't know how to use) where the cursor will still exists and clicking will move it around, but the window doesn't respond to keyboard inputs.

kstrauser• 2 years ago

Especially with the native compilation in newer versions. Wow! That was a night and day difference. Before, I tolerated it. Now, I very rarely wait for anything.

mplanchard3• 2 years ago

Yeah it's much better than it used to be for sure. I recently dumped doom-emacs and went through the process of setting things up from scratch, and mostly performance is pretty good.

I think that it still struggles a bit when I have many (>100) buffers open, largely I think because of anything that has to do window management winding up iterating over every buffer, and it turns out a lot of things (both internal and third-party packages) wind up doing this on various hooks that make the overall experience feel sluggish.

I also still see occasional performance issues with eglot/LSP on very large projects, especially around input feeling laggy while the language server is churning on something.

In general, it's frustrating when stuff that /should/ be in the background and not have any effect on actual editing latency winds up causing slowness or hangs. A good example is any time font-locking gets complicated, e.g. on very large files (which again has improved in recent versions).

3836293648• 2 years ago

Emacs is snappy in the terminal with the tui version while the gui versions are still really slow for me. Hopefully someone will make a fast frontend with GPUI or something because the lisp engine is certainly fast enough these days

jojohohanon• 2 years ago

Huh?

I (used to) use it almost exclusively with eglot lsp to python language server (Jedi I think). I run emacsfoacosx 29.2 and now .3. And I’ve used it since 1996 on emacs 18 on a b/w sun workstation.

But most recently on the last 2020 intel MacBook Pro.

The cursor moving speed through a source file is atrocious. Maybe 3 - 4 lines per second vertical and similarly horizontal.

The shell just freezes on long lines and forget about font lock for multi MB json.

All of these tasks would be hard a decade ago but now aren’t even table stakes.

It just /feels/ sluggish.

I reluctantly just gave up. It was fast way back then but I think workloads have changed. I tried zed for a bit but have now reluctantly gone to pycharm CE. If you accept the different windowing metaphor and add bindings for C-a and C-e and friends (some are standard) it’s not bad. And never sluggish (same hardware).

I love emacs but for my outlandish workload of python programming and wrangling multi MB text output it just doesn’t perform.

I speculate it isn’t straight line speed but threading that is hurting perceived latency.

ghosty1413• 2 years ago

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.

Yeah while completely unrealistic some way to make interfacing with emacs packages would be nice.

There seems to be a magit like interface in the works: https://lisp-journey.gitlab.io/blog/oh-no-i-started-a-magit-...

stackghost3• 2 years ago

Has anyone used this?

I have, it's awesome. There are some rough edges and some niceties/third party packages from emacs that I missed, so I ended up going back, but lem is very promising.

nurettin2• 2 years ago

niceties/third party packages from emacs that I missed

Was it magit?

az09mugen2• 2 years ago

Does it have multiple cursors like https://github.com/magnars/multiple-cursors.el ? I consider it as a mandatory feature.

cayley_graph• 2 years ago

Yes I'm waiting for a nixos package. I have used it a bit through the Docker image and it's super cool. I can see it succeeding emacs. Seems like it's even more hackable than the latter, since it's all written in Common Lisp (there's no C core).

globular-toast• 2 years ago

I think every Emacs user has thought the same thing. The trouble is Emacs isn't the interpreter, it's the enormous amount of Lisp code written for that interpreter. This isn't the first CL Emacs and probably won't be the last. For a CL version to work you've got to be so good it attracts enough people over despite it being initially worse. But that group of existing Emacs users is already tiny and they spend enough of their time hacking Emacs... This one not being GPL doesn't help either.

jfaz16• 2 years ago

To be fair, this project is not a CL Emacs. It's a separate editor doing its own thing that happens to share the same keybinds and a few architectural decisions.

cmrdporcupine4• 2 years ago

It's quality and making rapid progress.

I've been using (GNU) emacs on and off for, uh, 30+ years. And it's close enough that it mostly feels right. But many things my fingers and eyes are used to are different enough to be jarring that I'd have to re-learn some things.

Still, I just fired it up and started editing Rust code and -- unlike GNU Emacs -- it came with a pretty much working LSP auto completion setup out of the box. It's not RustRover level fantastic, but it's good enough to do work. And a lot just works out of the box that has to be configured and set up manually for GNU Emacs. E.g. it comes with a project explorer like Emacs projectile, already all set up.

I just wish I could make it bring up the M-x line on the bottom like GNU emacs, instead of in the middle of the screen?

EDIT: nevermind, found it:

  (setf lem-core::*default-prompt-gravity* :bottom-display)
  (setf lem/prompt-window::*prompt-completion-window-gravity* :horizontally-above-window)
  (setf lem/prompt-window::*fill-width* t)

yashasolutions• 2 years ago

nice but no org mode yet...

seanw444• 2 years ago

Yeah the real power of Emacs that keeps me with it is the packages and community surrounding it. Org is irreplaceable to me. I use Calc all the time, and Magit even more. The GUI and the associated ability of having different fonts and font sizes at the same time, with embedded images and whatnot, makes it feel capable as more than just a text editor. Heck, I even browse Gemini with Elpher inside Emacs. Also the discoverability of everything within Emacs itself is unparalleled.

If Lem is eventually able to replicate these things (or even improve them), I'll have no problem switching.

lanstin4• 2 years ago

It would be cool if it took off, SBCL is very nice, but then so too is Mach and yet HURD isn't really there yet after 20 years.

ksp-atlas• 2 years ago

I've used this, you can tell it's still in development but it feels great

armchairhacker• 2 years ago

Does it use Common Lisp for scripts instead of Emacs Scheme? What other features does it have that give it an advantage over Emacs?

jfaz16• 2 years ago

Pretty much. The whole thing (including scripts, packages, configuration, etc.) is written in CL, there's no C core (minus a bit of ffi here and there for e.g. shell interaction). This makes it really easy to modify the editor's source code while you're in it. Another bonus of everything being written in a general-purpose language like CL is that you can leverage any random CL library for your config/packages, and don't have to do janky stuff like lsp-bridge calling Python in order to have non-blocking completion.

Besides better defaults, it supports multithreading and launches instantly, feeling a lot snappier all-around. When I first started using lem, I basically just used it as a shell editor for non-code stuff like text/config files, since it started much faster than emacs (I don't like using the daemon) and had the same keybinds. At some point I started using common lisp for a personal project and it's become my main editor since. Development is also super active.

gibsonf1• 2 years ago

This looks fantastic!

BoingBoomTschak• 2 years ago

I'm watching it with attention but some stuff is concerning:

* Some binaries in the source tree like https://github.com/lem-project/lem/tree/main/extensions/term...

* Commit messages aren't really descriptive.

* PRs and issues lingering in the void.

* Working around the strange inferior process thing (cf https://github.com/lem-project/lem/issues/1076) 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.

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.

HexDecOctBin2• 2 years ago

Also, weird passive aggressiveness in the issue tracker without actually fixing the issue: https://github.com/lem-project/lem/issues/1359

MarceColl• 2 years ago

He is japanese and I met him in the european lisp symposium. He doesn't speak english at all and he mostly uses automatic translation, any english weird thing or strange sentence can be probably attributed to that. He was very nice

CodeCompost• 2 years ago

The only reason why I use Emacs is org-clock-mode. Can I use it with Lem?

ghosty1413• 2 years ago

Org mode seems to be missing right now. It looks like its aimed more at only programming right now but I can totally see it getting a proper orgmode in the future. It's far more hackable than emacs is!

downut2• 2 years ago

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 which frames are important when is helped by where I place the frames on the screen. This is optimally efficient for me, it's a pleasure to work in.

Although I dearly loved terminal turbo pascal/c, I really detest tiling only window managers/apps.

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.

[edit: make it clear I built the sdl2 variant on debian testing]

downut2• 2 years ago

A yes or no would be cool. I understated a bit on why I love working this way, and it is interesting that that isn't important to the several enthusiastic advocates here. Noted.

jfaz16• 2 years ago

Sorry, I only recently started contributing and don't really have an answer to your question. I'd venture to say there aren't that many lem devs/"enthusiasts" browsing this thread so I can only speak from my own limited experience. You're free to open an issue to get better feedback though. Also, I'm having trouble visualizing the workflow you mentioned with overlapping frames, do you have a clip/screenshot or something? Using the mouse to focus overlapping emacs frames just sounds like a window manager thing in my head.

natmaka• 2 years ago

E. Naggum published quite a few pertinent ideas and code: https://www.emacswiki.org/emacs/ErikNaggum

cmrdporcupine4• 2 years ago

It's odd to describe this as "emacs-like". It is 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.

ghosty1413• 2 years ago

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.

Lem: Emacs-like editor written in Common Lisp

Related Stories