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.
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)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.
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.
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).
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.
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-...
* 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.
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]
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.
If Lem is eventually able to replicate these things (or even improve them), I'll have no problem switching.