Emacs is my new window manager (2015)
howardism.org
howardism.org
That's a really big ask. The entire ecosystem around Emacs isn't built for multithreading.
What I mean is having threading capabilities available for things that want to (and should) use them. AIUI some support for that was added in emacs 26, so it might already be good enough.
The relevance is that EXWM is single threaded, so the window management blocks when emacs does. I don't find that much of a problem with EXWM but I doubt it would fly for a Wayland compositor, though perhaps the separate server used in that emacsconf talk sidesteps the problem.
1. Kristian Høgsberg the founder of wayland, did all the DRI2 work on xorg before becomming frustrated 2. Peter Hutterer was a main xorg developer and has been behind the wayland input system 3. Adam Jackson, long time xorg maintainer essentially called for moving on to wayland https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server... (I found that he was involved in wayland discussions, but not sure if he contributed code) 4. you already mentioned Daniel Stone
The only main xorg developer not involved in wayland arguably could be Keith Packard, although he made a lot of the changes for xwayland so I'm not sure if it is correct to say he did not have wayland involvement.
So who are the "vast majority of X.org developers"? I think people always read about the couple of names above and then think, "well there must have been hundreds of others", because they thought xorg was like the linux kernel. AFAIK xorg always only had low 10s of active developers.
This doesn’t even include the XFree86 CVS commit history and older, which accounts for most of the code in X.org. Some of those people may actually be dead now.
>AFAIK xorg always only had low 10s of active developers.
There are 38 people with 100+ commits, which obviously counts as a major contributor.
This is why openbsd is great.
I don't care about the drama that happens in Linux land at all.
I have been experimenting with xdotool windowmap/windowunmap and override_redirect (and maybe LD_PRELOAD?) to try get something like EXWM to work without creating another X server, by capturing windows. I'm doing this in vim though.
By the way, neovim has an apparently working EXWM-like plugin, NXWM/nwm: https://github.com/altermo/nwm
You need to install just the Emacs package Emacs Desktop Window Manager (dwin) https://github.com/lsth/dwin, for example from MELPA. Currently it works with X11 window managers as well as with KDE/KWin on Wayland or X11 (using xdotool and kdotool, resp.). I am using it all day myself on KDE/KWin Wayland in my standard setup and there it works fine.
(I am the author.)
Once you have that taste of freedom - there's no going back. The traditional way of "write, save, reload/restart" would feel so clunky, annoying and stupid.
And you can absolutely do this as long your WM supports some kind of IPC. I'm slowly building my Hyprland config in Clojure using babashka. I wish I could share it publicly, but it's still in early experimental stage - too messy, too opinionated, there are some bugs, and I still may decide to switch to Janet, CL, nbb or some other Lisp option, I'm glad we have numerous options to choose from.
So, for example, I would write in my editor an expression to get the list of windows on the current display, then I can immediately map/filter through them, group, sort, read any parameters, etc. Then without missing a beat I can apply some transformations - programmatically move any window, resize, etc; on the fly, like playing a fucking video game.
Compare that to "more traditional" approach of issuing commands, then piping them to jq or something, then figuring out where the stuff is, then writing that into a file, then having your WM to pick up those changes, often you'd completely lose the state, then you'd have to go back to the script files, etc. I, don't have to save anything anywhere until I'm sure that shit works - I simply eval things on the go - I can "touch, grab and interact" with entities immediately after querying their info, there's no physical, mental or contextual separation here - I don't have to write something in the terminal, then something in one of my scripts, some parts in some other file, etc. - everything controlled directly from my editor.
Here's more practical example. Hyprland has something called Hyprsunset to deal with color temp and gamma. I wrote an extension that changes display color temp based on time of day - it's a simple clojure.core/async go loop, it reads from a hashmap where specific hours map to temperatures and then checks every 10 minutes; if it's time to apply new color, it does. That took me just a few minutes to whip out with a connected Lisp REPL. I'm pretty sure, it would've taken me far longer without it. The way how the "true" REPLs work (which e.g., Python one is not) simply is shockingly crazy awesome for rapid prototyping. Why more programmers don't do this is a complete mystery to me - getting into Lisp is not even that difficult, Clojure for example is far more simpler and more straightforward than even Javascript and Python. These days, you don't even need to know Emacs - install Calva for VSCode - that's all you need, it has quickstart guide and all.
I thought hyprsunset already changes the temperature automatically for you. Nevertheless, sounds interesting, do you have this loop started when you launch your editor?
What is the difference between a "true" repl and one like python?
Thanks for all the detail.
It seems it does now, when I wrote my thing there wasn't multiple profiles feature - it's a very recent feature that was added not too long ago. I guess I can remove my custom script now. But then again, if it just works, why bother?
> What is the difference between a "true" repl and one like python?
Like I said, all stages in R.E.P.L. do differ:
Read: In Lisp, lexical analysis and tokenization keeps the forms as data - no need to do much here. In Python, this step produces private AST representation you cannot easily access and modify.
Eval: In Lisp, the compiler just walks the forms freely - because they are already in the shape; in Python, parser-generated AST nodes get passed to compiler, AST is opaque to user code, it doesn't allow manipulation semantics, Macros in Python require AST manipulation libs - heavyweight, not first-class; This is fixed compile phase in Python - no runtime AST rewriting possible.
Print: Serializes eval results back to readable representation. In Lisp - this is trivial because results already data structures in the right shape. In Python, you can't feed printed output back through eval and get meaningful metaprogramming.
Loop: Reader directly consumes user input, they are just native forms, compiler sees the code like data, this allows transparent metaprogramming - you can easily write code that re-writes itself. In Python: string input first compiles then gets processed for execution; metaprogramming is pretty opaque - reconstructing the AST is much more difficult - not easy to write code that re-writes itself; eval/exec operate on bytecode, not source semantics.
In practice, what these seemingly unimportant differences make possible is: first of all you get to write code as you are playing a video game - you just write shit and eval things, and immediately make things fly - find Figwheel demo video, Bruce Hauman there writes a clone of FlappyBird where he manipulates the physics directly from the editor - without any saving, reloading anything, without state changes, etc., he literally uses his editor like a joystick to move the effing bird around. And it's some darn old flick - there's nothing "revolutionary" about that technique - Lispers been doing shit like that for a long time. Or search up on YouTube "Clojure/Overtone DJ programming", where folks are playing music while manipulating some code in their editors, all in real-time. Or check this out - we run our services in k8s cluster. In staging env we maintain a REPL connection, so if we need to test something out, we just connect to it, change the code, eval and manipulate our entire pipeline directly from our editors.
These differences in REPL also open up metaprogramming otherwise much harder to achieve. Like for example, you can write code that says: "here's the server part, here's the client part" and then let the multi-phase eval figure out the semantics - sometimes, these semantics can mean that the server part actually executes in a different runtime - checkout Hyperfiddle/Electric demos - some of them are jaw dropping - you write code in one place but some of it executes on JVM, some in the browser - completely different runtime. Same code, unified logic, lives in one place - goes to run on different worlds.
I've been using it for a w while, and recently finally got fed up about terminals on my macbook not behaving as nicely as the ones on my linux box with proper tiling window managers, so spent some effort to make SSH into a terminal with completion easy from emacs, and now mostly handle terminals in emacs.
This matters a lot to me because the proprietary build/test tool at work likes to dump the stack trace for every failing unit test.
On top of that I'm using eyebrowse to have multiple workspaces, and some hooks around buffer switching that switch to the workspace a buffer is on instead modifying the current workspace.
I struggled quite a bit with the xinit ath the start, and I had to switch to other terminals to get back to any UI. But now I have a pretty consistently well-running EXWM, only from time to time (once a month) it freezes. Most of the time, because I quickly want to do sth. Mess up pressing multiple wrong key combinations and am stuck with a frozen ui :D For login I use lightdm, that will then load emacs.
What my key pain points still are:
- char and line mode Switching between them is easy, but having different modes, in different buffers can still sometimes mess up with my keys. Esp. when pressing Ctrl-q for escaping, just to realize that this is in line mode, and closing the window, instead of staring a actual sequence, like C-q C-y. Also, when coing through my buffer list, while having the preview active. So in buffer list, use C-n, and when the preview then shows a buffer, that is in line mode, that will capture the focus, and the next C-n will be send to the buffer, instead of the buffer list. Leaving me with a open buffer list in the minibuffer, that I have to manually close.
- some webpages e.g. payment providers open up a popup for confirming. From time to time, this popup is - in the background somehwhere - or floating - or not findable at all, even in my buffer list This is rare, but it happens. And when it happens, it's very annoying to interact with it
- when altering my emacs init config, and rebooting, and I messed things up. Then there is no way other than switching to tty1 and roll back the changes. Though I guess I could change that, through having some kind of check before saving.
- Not a pain point, but I still haven't gotten to the part of using it with multiple monitors. Looking at the config I always say that "I'll do it soon" >D
But overall happy! And thanks to howardism.org for all the wonderfull great emacs write-ups he has. My all time fav. is still the Literate DevOps article, to which I came back often in the past. And now that I think about it, I should re-read it! Thanks Howard!
>only from time to time (once a month) it freezes
I'm not trying to call you out personally as I've said and thought similarly in the past but truly what an indictment on the state of software that your whole desktop freezing once a month is considered ok and running consistently
I'm still someone who powers off his computer when I'm done with it for the day so I almost never get crashes or freezes.
https://web.archive.org/web/20041030060909/http://www.inform...
Also, the psychotherapist was one of a kind ;)
Personally, I could live with tmux or zellij as PID 1. Because from there I can do everything, except GUI. Might as well use Sway then to achieve virtually the same.
That said, i did not give it a fair shot. Does anyone have any good resources to get started? E.g lazygit has a good 15min vid to get u up to speed
The key bindings are sort of the least impactful idea behind the editor. The defaults are indeed ancient and opinionated, and don't match well with what other environments ended up adopting. They do work well for the most part if you want to take the time to learn them, though. But everyone has their own set of customizations[1], usually going along with a preferred set of physical key remappings[2]. Lots of folks use modes like Evil to get vi bindings, etc...
The point is to think hard about how you use the editor and start working on making the editor work the way you need it to. Binding fluency will fall out naturally.
[1] For myself, I'm mostly default. But for example I dislike the defaults for C-t and C-z which IMHO are footguns, and remap those to "top/end of buffer", functions I do use a lot and whose defaults are clumsy.
[2] Ctrl to the left of A, obviously. But also the key below '/' really wants to be Meta and not whatever else the manufacturer put there.
There’s some terminology to learn to make sense of the commands. And the default keybindings are also useful to learn (and you can find them in anything that uses the readline library and equivalent: Bash, zsh, psql,…. You can also find them in macOS text widgets).
But the thing is that Emacs have a lot of commands. They are assembled into packages and due to the nature of Elisp, can be edited and patched live. While it easy to get started (videos on youtube, the emacs documentation, the “Mastering Emacs” book), After a while, you config can become alien to anyone else. But it will stay discoverable as Emacs have a great help system.
If anything, this is what pushed me towards emacs vs having to learn separate keybinds for vim/neovim. I wanted a terminal based TUI text editor that followed the conventions of keybinds I already understood. I switch from Mac to Windows to Linux quite often, and I am constantly hitting ^+a to get to the front of the line and constantly frustrated when it doesn't work on some OS or only works in some context. It's fantastic on macOS, ^+w does the same thing in my terminal that it does in my text editor that it does in my web browser that it does in my slide deck. It also works because macOS moved the common "CUA" shortcuts for the GUI apps to command/Super, so Ctrl isn't overloaded with shortcuts, leaving things like Ctrl+c to send a SIGTERM and Command+c to copy without fuss. Plug in a keyboard to an iOS device and they work over there most of the time too!
I wish it wasn't such a ballache to replicate this on Linux, even if the various forms of text fields in the GUI frameworks don't respect it.
Emacs has its own tutorial (Help -> tutorial from the menus), which is a pretty good introduction. Learning to get help from Emacs itself is a bit of a learning curve, but really beneficial.
Learning to the use the help tools properly was something I didn't get around to for years, but I wish I had sooner.
Years ago it was remarkable for software to have docs built-in as Emacs does.
Then for many years it was standard for software to have help files, and it seemed anachronistic for Emacs to loudly proclaim it is self-documenting.
Now in the Web and LLM age, much software doesn’t even try to have built-in help or even much documentation, and it’s again remarkable that Emacs is self-documenting, especially the part of Emacs that users can program.
Emacs' notion of self documentation refers to something slightly different than the fact it has online help files. The help facilities can query the Lisp runtime for things like functions and keybindings. These update dynamically as the system is reconfigured. The result is something that isn't quite as cleanly presented as an online help document, but has the benefit of being deeply integrated into how the system is actually configured to behave at the moment. Very cool, and very much dependent on the open source nature of emacs.
Doom Emacs install from scratch takes less than that.
To the eyes of his employer installing a personal VM is probably exactly the same.
I have the same problem, but I'm not sure if a VM is a good solution. The work OS has full access to the VM and I don't trust putting my personal things even in the VM. (I consider the work laptop backdoored and full with spyware.)
The author mentions in the footnotes he mostly uses this setup for note taking. That makes sense as he probably remains in one window for extended periods of time.
GUIX, EXWM, and Emacs are home for now :)
Something like:
# start other stuff
emacs &
exec kittyIs there a live release/support/discussion ecosystem for ratpoison in 2025 ?
https://www.nongnu.org/ratpoison/
http://savannah.nongnu.org/projects/ratpoison
I used it for a while back then, before switching to IceWM because it was more fun to configure. Prepared me well for a much later move to i3.
For support, I'm sure the users in the past has generated enough forum threads for you.
In all seriousness though, I've used two different machines and three different distros with my current setup on top and it all feels the same. I didn't even notice in my daily interactions with the system.