[HN Gopher] Lem: Emacs-like editor written in Common Lisp
___________________________________________________________________
Lem: Emacs-like editor written in Common Lisp
Author : amarsahinovic
Score : 160 points
Date : 2024-08-26 14:22 UTC (4 days ago)
(HTM) web link (lem-project.github.io)
(TXT) w3m dump (lem-project.github.io)
| mplanchard wrote:
| 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 wrote:
| Emacs is pretty snappy these days, what kind of performance
| problems are you seeing with it?
| stackghost wrote:
| 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.
| omaranto wrote:
| Emacs can run external processes asynchronously. It is true
| that Emacs locks up while updating packages but it is
| actually _not_ while downloading or unpacking them! It
| locks up while byte-compiling them. :)
| mmmore wrote:
| Maybe it can but it sometimes doesn't.
|
| I remember I looked into a lockup I was experiencing
| (this was a few years a ago so I forget the mode). Turns
| out emacs was writing to disk every so often and this was
| noticeably causing stutters in the main thread.
| aeonik wrote:
| You are correct, my emacs locks up constantly. Mostly due
| to linting and syntax highlighting, but also with the
| emacs terminal.
|
| It really depends on the package, but too many
| fundamental packages are still operating in the main
| event loop.
| stackghost wrote:
| Okay, well either way, the UX is atrocious.
| kleiba wrote:
| What is it that bothers you about the UX?
| nurettin wrote:
| > would never describe it as snappy. The entire thing is
| single threaded so the UI locks up at the slightest
| provocation
|
| This part seems to be about the User eXperience. (which I
| agree with, but elisp can start child processes and wait
| for the results asynchronously, so this is the fault of
| whoever wrote the code https://www.gnu.org/software/emacs
| /manual/html_node/elisp/Ou... )
| mmmore wrote:
| 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 wrote:
| 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.
| lanstin wrote:
| Yeah, it's positively snappy.
| medo-bear wrote:
| I love Emacs and it has been my number one tool for a long
| time. It is definitely more efficient with native
| compilation but there are still some issues. For example,
| get a large code base and obtain all occurrences of an
| expression in the whole code base. Every IDE is going to
| stutter on this but Emacs will pretty much lock up until
| this completes.
| mplanchard wrote:
| 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).
| lanstin wrote:
| Yeah, it's better to use one emacs per project, and have
| less buffers open at a time. Not just the snappiness but a
| lot of the (out of the box, no special modes) keyboard
| buffer navigation stuff doesn't scale to hundreds of
| buffers. Maybe if I had better file naming conventions, but
| I tend to have a main.go in each cmd and sometimes even in
| pkg. I also rarely learn new modes/packages, as they aren't
| in on the VMs and so on that I also like to use emacs on.
| 3836293648 wrote:
| 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
| ghosty141 wrote:
| > 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-...
| stackghost wrote:
| >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.
| nurettin wrote:
| > niceties/third party packages from emacs that I missed
|
| Was it magit?
| dartos wrote:
| It's always magit
| jfaz1 wrote:
| Lem has Legit. While missing some features, it works well
| enough for the daily add/stage/commit loop that makes up
| 90% of my git commands. It also uses less git commands so
| it's a fair bit snappier than Magit on large repos.
|
| I can see the lack of org-mode being a dealbreaker for
| some, but I personally use markdown for my notes/docs so no
| issue there.
| cayley_graph wrote:
| 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 wrote:
| 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.
| jfaz1 wrote:
| 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.
| yashasolutions wrote:
| nice but no org mode yet...
| seanw444 wrote:
| 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.
| lanstin wrote:
| 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 wrote:
| I've used this, you can tell it's still in development but it
| feels great
| armchairhacker wrote:
| Does it use Common Lisp for scripts instead of Emacs Scheme? What
| other features does it have that give it an advantage over Emacs?
| jfaz1 wrote:
| 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 wrote:
| This looks fantastic!
| BoingBoomTschak wrote:
| 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.
| HexDecOctBin wrote:
| Also, weird passive aggressiveness in the issue tracker without
| actually fixing the issue: https://github.com/lem-
| project/lem/issues/1359
| MarceColl wrote:
| 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
| HexDecOctBin wrote:
| I see, that explains it. Apologies for jumping to
| conclusions.
| jfaz1 wrote:
| Hahaha I've seen some pretty nutty maintainers so can't
| blame you! That being said I can vouch for the guy, he's
| extremely nice and responsive.
| adamc wrote:
| Thank you for this kind of note... helps bring the humanity
| back to the faceless internet.
| CodeCompost wrote:
| The only reason why I use Emacs is org-clock-mode. Can I use it
| with Lem?
| downut wrote:
| 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]
___________________________________________________________________
(page generated 2024-08-30 23:00 UTC)