What are your thoughts about these? I know there was LLM Assistance but we waited so long for a Replacement for EXWM in Wayland and now with a little help from LLMs and with plausible ideas (like taking bits of Niris Code) we get them. Somebody else seems to found a way with LLMs to get a better Display Engine. We are fighting these but one day that would be the start of something mature. EWM seems to work already and Neomacs also has something going. I know a lot of people dont like that Claude is everywhere but we are waiting for so long for a modernized core and we failed so many times. And now we really are getting small steps with Results. Is that nothing to be cheering for? I know i would be happier if Remacs or stuff like that would be successfull.
Not happy about the LLM agents involved because of the unsolved legal problems.
Does EWM and Neomacs work together?
It would be great if the move form elisp to guile would also solve the single thread problem.
what do you mean by the legal problems?
i want to try it out. it would be crazy if it would work together. more performant emacs with gpu sideloading and wayland with a seperate thread exwm. would be awesome. if guile would be implemented instead of elisp even more cause we just would have guile for everything
AI work canāt be copy righted AFAIK.
Also what does the license of the training data mean for the generated code?
Currently I will only toy with LLMs and itās a wash for my use cases. For single agents itās like having to babysit an apprentice or intern. Colleagues work with multiple agents and report good results but itās like working with outsourced teams with a faster turn around time.
I tried out neomacs a couple days ago and it did not work well at all on my computer. To me, it seems the largely unguarded use of AI and high velocity of the project thanks to AI with little oversight made the project seem flashy and cool but ultimately have poor quality. I would be worried about making my workflow dependent on a tool that has demonstrated to me that it is fragile and dependent on AI.
This is my first time looking at EWM, and I havenāt used it yet, so take this next part with a grain of salt.
From the EWM readme:
Writing a Wayland compositor from scratch is a staggering amount of work. I wanted to switch from EXWM as soon as possible, so the initial bootstrap was done with Claude, which helped a lot in reverse-engineering the brilliant niri codebase and surgically extracting the pieces relevant to EWM. Inherently, this means the codebase still needs validation and cleanup, which is the current priority
The approach to AI between EWM and Neomacs seems fundamentally different. The commit history on EWM and this message make it seem as though the author is very aware that vibe-coded/AI dependent projects are inherently prone to bugs that are hard to solve due to there being nobody who actually knows the codebase, and I respect them for making it their chief priority to clean up the poor quality work left behind by claude. This understanding and desire for quality makes EWM seem significantly more hopeful to me than Neomacs.
I agree with all the Replys. Hopefully EWM stays on track and could be useful.
A bit tangential but when I first saw āNeomacsā in the title I thought you were talking about this other project: GitHub - neomacs-project/neomacs: Structural Lisp IDE/browser/computing environment Ā· GitHub
On a more related note, while Iām of course happy with the work in this area, I still have the lingering suspicion that more investment in non-Emacs, but still Lisp window managers (and more Lispy, Emacs style tools) would pay off better in the long run. Like in the short term, I would love to have my window manager nice and programmable in a Lisp, but I also think that you really start to push Emacs (as an implementation of a programming language) a bit too far when you do more intensive things like this with it. There are too many random Emacs things that are blocking. When it is just Emacs that freezes for a second it doesnāt bother me too much, but if my whole WM hangs when I accidentally run a code block the wrong way in Org, I donāt think Iāll like that.
Of course I suppose it is possible to run multiple Emacs (like one as a WM and use another inside it) but still, I think a more concerted effort on tools in a general purpose focused Lisp (Common Lisp or Guile) would ultimately get us to a better place than digging into Emacs more.
(Though donāt get me wrong, Emacs is still my favorite program, and I will take Emacs Lisp over basically all non-Lisp languages, but I have to say that I think it would do more for the goal of āLispy Emacs goodness everywhere!!!ā to invest in say Nyxt over say the EAF browser).
stumpwm is a common lisp window manager. It is available for guix. I think under stumpwm if your emacs stucks, you can still switch to other windows.
Yep, I know about Stumpwm and Mahogany. My main point was just that it would be nice if more of the development activity were focused at developing building up the non-Emacs (but still Emacs in spirit) applications and their ecosystems. I love Emacs, but it has so much baggage (both in terms of code and in compatibility liability) that makes it hard to adapt to things well outside the land of text.
Probably because of the relatively low development investment in non-Emacs Lisps, it makes it easier to get something kinda-ish working in Emacs, but in the long run, if we wanted to make something that would truly transcend all the other options in non-text domains in the same way that Emacs does for text, I think we would need to build in another Lisp. And for that to happen I think there needs to be more ābasic developmentā (in the same sense as ābasic researchā) for these other Lisps. They are more powerful, but as of yet, still seem to often lack some of the wide and well maintained library base that Emacs Lisp provides.
Would Guile work or is it not fitting because itās scheme and doesnāt compile to a binary without a C main.
Iām not sure if you were asking me, but if you were, yes Guile would be totally fine*. I personally tend to use Common Lisp because Iām more familiar, SBCL is extremely fast, and it often feels more malleable to me (though that could easily just be a result of my experience). I know there are at least some Guile window managers for X and Iāve seen a Guile module for controlling Sway.
Iām not sure on the technical considerations but Iām very confident that a Wayland compositor that can be configured and programmed to a reasonable extent can be made in Guile.
* As a side note, I consider Schemes to be Lispsāanything with a reasonably powerful macro system and homoiconic syntax where operators are grouped with their arguments can reasonably claim to be a Lisp in some sense (though the claim can be weaker or stronger based on various factors). I think distinctions made based on more minute characteristics are pedantic (which isnāt to say those characteristics arenāt ever important, just to say that they arenāt distinguishing characteristics for the Lisp family).
Emacs like architecture would mean a core in a language like C or Rust and a language like Elisp or Guile to build all the logic in. As Guile was build for this embedded use case I and Iām a Guix user, I was thinking about it first.
Hi everyone! ewm author here.
So nice to see it being discussed, I hope you will try and like it! Please report any issues/bugs youāll notice as every report at this stage makes the window manager solid.
On the topic of AI usage, I still believe that a tool is just a tool, nothing can replace a human brain, yet some things for sure can make it lazy!
My approach to contain the hallucination drift is somewhat simple; after setting the fundamental architecture around dynamic module, Iāve constrained myself to never bring anything that niri codebase doesnāt already have. So in practice every promt-fix iteration just shaped ewm to be more niri-like, up to a point where LLM support is not bringing much benefit over writing code by hand.
Of course it also helps to have years of experience in the tools used. At this point I use ewm as the only solution for work every day, so if I fail to understand how to fix something, Iām shooting myself in a foot.
Neomacs seems to be an interesting project, but Iām a bit careful at this point as Emacs forks have a long history of being deprecated after some years of development. LLMs can massively speedup bootstrapping a project, but itās usage undermines fundamentals of a healthy open-source community, which is important for any long-term project survival. I much more prefer less radical approach of isolated emacs patches that target specific issue, like GPU rendering support: GitHub - ArthurHeymans/emacs at skia-30.2 Ā· GitHub
Btw, for those who prefer to keep their hands completely clean from LLMs, I highly recommend to check out another try on a Wayland-based emacs compositor from my great friend tazjin: https://code.tvl.fyi/about/tools/emacs-pkgs/reka Itās based on River, so with a small toll in feature limitations it helped to contain the complexity enough to write everything by hand in relatively short terms.
Greetings. Neomacs is currently a work in progress and is not yet ready.
As of May 3, 2026, Neomacsāwhich is written entirely in Rustāsuccessfully compiled (cargo xtask fresh-build --release). I am currently still engaged in intense development and havenāt yet had the opportunity to test it.
I believe that, through continuous and iterative development cycles, Neomacs will evolve into a modern and clean architecture, characterized by high-quality code organization and exceptionally comprehensive unit and integration testing.