EXWM (Emacs X Window Manager) | Hacker News Reader

EXWM (Emacs X Window Manager)

github.com

126 pointstosh57 comments

This sounds like a comedy hack but isn't. I tried it out for a lark and now it's been my only wm for 3 years. Absolute genius.

I should try this out on my home pc.

> This sounds like a comedy hack but isn't.

A true comedy hack could be running and editing files in gvim, but to manage gvim's windows in Emacs.

you could just run vim in eshell

Not really. You could run ex I guess but that would be awful. I suppose you mean running it in M-x term.

Vim doesn't run in Emacs' terminal because it doesn't have ncurses support. It is possible to start Vim inside Vim's terminal buffer, but it's often not usable, as the outer Vim tends to catch all the input. I usually tend to remember that after I ran `git commit`...

vim is definitely runnable in emacs's vterm, which is more similar to the terminal in Vim than any of emacs's shell, eshell, or eterm modes.

As an evil user, I tended to remember this after I ran `git commit` and then try to remember how to pause evil so I could address vim. (I now use `with-editor` to set $EDITOR back to the parent emacs, and have mostly switched to magit)

At one point before Spacemacs was a thing, I had my 'stupid Emacs trick' - I had set up keybindings to invoke Vim as an external editor for Emacs. It took an open buffer and opened ansi-term and executed Vim on the file from the original buffer. I got some perverse pleasure in running Vim in my Emacs instance.

I don't remember if I got as far as saving non-file buffers as temp files so they would be accessible to Vim or not. That would have been the next logical enhancement. Maybe it would also be possible to pipe the buffer directly into Vim? I'm not sure if Vim would display in the foreground if you did that or not. I feel like I've had situations where piping things into Vim managed to wedge it in the background, but some of that was on Windows where console process communication is a wasteland of broken dreams.

Essentially => https://github.com/timor/spacemacsOS

What makes it worthwhile to you?

It’s not entirely clear to me from the page what features set it apart. I guess part is familiar keybindings if you’re an emacs user?

The screenshots look like it does some tiling, is that a good experience? I use i3 so would be curious to know how this would compare.

Every X window is a buffer, so you have all of emacs's powerful buffer switching programs (see: ido, helm [1], ivy [2]) for focusing windows. Also there are multiple interesting solutions to managing window splits [6], moving windows [3][4], saving their configuration [5], etc.

[1]: https://github.com/emacs-helm/helm

[2]: https://github.com/abo-abo/swiper

[3]: https://www.emacswiki.org/emacs/WindMove

[4]: https://github.com/abo-abo/ace-window

[5]: https://github.com/Bad-ptr/persp-mode.el

[6]: winner-mode, one of my favorite things. https://www.emacswiki.org/emacs/WinnerMode

Interesting side note, WindMove was originally authored by founder of wiki leaks Jullian Assange.

It's primarily useful to people who already use emacs a lot, I think. Not sure I'd recommend using emacs just for EXWM, as some people seem to do with magit or org-mode.

The main problem it solves is that emacs is a tiling window manager (in a loose, non X-specific sense), so if you spend the majority of your time in emacs it gets quite annoying that you're having to use two different paradigms to manage windows: one for managing emacs "windows" and the "buffers" that they "visit" and one for managing X windows, of which emacs itself is one. EXWM makes X windows behave (mostly) as if they are emacs buffers, so you can use the same powerful tools to manage them.

As an example, I use ivy (https://github.com/abo-abo/swiper) so for switching between buffers I get a nice incremental fuzzy-matched buffer list. With EXWM that same buffer list also contains my web browser and other X applications.

I've written a toy window manager so I have some sense for what making a real one would entail. I've been using emacs for 20 years or so, so have some insight into that. I am in awe at the dedication and attention to detail it must have taken to turn EXWM from a crazy idea into a solid WM that is completely usable as a daily driver.

> it gets quite annoying that you're having to use two different paradigms to manage windows

I can imagine that EXWM eliminates the need for SUPER, which for me would free a modifier pair for a useful LVL3.

What is LVL3 ?

Sorry: level 3. It's the modifier that ``comes after shift'' and accesses special symbols. Some operating systems call it `option' and `alt gr'.

I currently have a super on both sides and need to shift super in order to get level 3. Some pedals would be nice.

Doesn't this mean that, if EMACS freezes, your window manager freezes? How does it compare to XMonad and StumpWM?

Correct. It does. I was on EXWM for one and a half year, with all it's pros and cons.

I gave a lightningtalk on EXWM at Congress last year: https://media.ccc.de/v/36c3-10525-lightning_talks_day_3#t=14...

Note: I'm not the developer, I'm not involved with the project, I was just a huge fan of it. And still is. But it's too slow and buggy for me these days.

With the new native-comp branch (aka gccemacs) at least the slowness should go away.

If it's buggy I'll stick to XMonad. What are you using now?

I was using i3 before, so kinda went back to that and when that was set up I decided to try out sway again which actually did stick this time. So been on Sway for a couple of months :)

I was thinking the same, but as the pictures on the EXWM site suggest: could you not run a dedicated instance for the window manager? And do all your other Emacs tasks in embedded instances, so that the former is not so likely to crash?

The Emacs instance running as the WM is just Emacs in fullscreen. You can use it as your editor. But you can also launch X11 programs and manage them as you do with text buffers. Kill a program, kill a buffer. Same thing.

But you can, of course, launch a graphical Emacs within EXWM. There you get a second Emacs thread.

One can also put X11 buffers in char-mode to pass through keybinds directly to that window. That way you don't have to do weird sequences to pass through emacs keybinds to another Emacs.

You are not supposed to use the same instance for working and window-managing. Using a dedicated setup for EXWM and another for the rest is somewhat mandatory with this, to prevent exactly this problem.

EXWM has been my daily driver for years and I use the same Emacs for window management, email, text editing, IRC and a few other things.

This can be a problem if you choose applications (like Gnus) which are known to have slow, blocking operations but those usually have modern alternatives.

I really want to love this, but can't quite get there. I've tried this a few times. As a casual emacs user (for almost 30 years though) I like the idea but find the actual practice of using it fairly jarring. Probably if I was an emacs power user I would love this, but I've never become especially adept with managing buffers and windows in emacs and this really requires you to have that down pat. Nor do I think window management in X is particularly great when compared to some of the tiling window managers out there. On the other hand, I always felt that emacs within a tiling window manager was also very awkward.

I just tried again with one of the recommended configurations that uses ido and... it was confusing. ace-window looks fairly compelling, maybe.

I suppose the right approach to adopting this would be to spend some amount time with emacs full-screened first, trying to do almost everything in it, getting better with buffer and window management. Then make the jump to having it manage windows.

Meta: mods, please consider changing the link to the repo's root [1], since the screenshots page lacks a description of what the project is. It's easy enough to find the screenshots page by reading the root page.

[1]: https://github.com/ch11ng/exwm

I use Emacs every day, I practically live in it. However there are some things that I wish I could have:

- a good terminal mode so I don't need to switch to another terminal, the builtin terminals either lag badly after 10K lines of input or render/behave strangely when used with ncurses programs

- pervasive, non-blocking async, this has gotten better over time especially with language servers being on separate processes, however many common tasks block usage completely, such as upgrading/installing packages

The reason I bring this up is because imagine those points but applied to your window manager. Since Emacs is not multi-threaded, if something inside Emacs freezes your whole X session will become in blocked case you run Exwm. For the same reason, it is a bit more responsive.

For long output and ncurses, libvterm may suffice https://github.com/akermu/emacs-libvterm. The rest of the time, eshell is very comfortable for me.

> a good terminal mode so I don't need to switch to another terminal, the builtin terminals either lag badly after 10K lines of input or render/behave strangely when used with ncurses programs

I found vterm[1] to be pretty reliable for any kind of "advanced" terminal use. Also much faster when dealing with large amounts of output.

[1]: https://github.com/akermu/emacs-libvterm

Agree on the terminals - I've never got on with any of the emacs options. I use mate-terminal within EXWM, so at least my terminals appear in the buffers list.

EXWM does indeed block when emacs is busy. I haven't found it a problem with my usage, but I imagine it could be annoying. Killing emacs ends the X session of course, as it's the window manager, but I rarely need to restart emacs. Useful trick: If emacs really is stuck and Ctrl-G isn't working, switching to a virtual terminal (eg. Ctrl-Alt-F2) and running `killall -SIGUSR2 emacs` will usually make it snap out of it. (I haven't had to do that for months, though.)

> Killing emacs ends the X session of course, as it's the window manager

If killing Emacs ends the session, that must have a different cause. Killing the WM doesn't usually end the session.

You can load your long running emacs session in a separate session within EXWM. For some reason the thought never occurs to a lot of EXWM users.

https://tech.toryanderson.com/2020/10/19/emacs-in-emacs-a-tr...

> Since Emacs is not multi-threaded

Seems weird that no one would have built a multi-threaded emacs by now.

What people do with emacs always amazes me.

I'm not sure what experience you've had with Emacs, but many Emacs users think of Emacs as a platform (with unique benefits) rather than a text editor.

I use Emacs as a platform, can see the benefits of using Emacs as a window manager, but consider the disadvantages (in light of Emacs hangs or crashes) as too much, versus using i3.

Dose it have a text editor?

Man, I literally fell on the floor laughing :)

Sure, evil-mode can still be used.

It actually does :) https://github.com/agzam/exwm-edit

Coooool. Now I have to set up a testbed. I currently use stumpwm (http://stumpwm.github.io), which others interested in EXWM would likely find interesting. A Raspberry Pi running stumpwm and emacs has been my standard PC (well, that plus a bunch of AWS VMs for services and testbeds) for several years now. There's a chance my stumpwm (which is really just there to launch emacs in X mode) will get replaced.

Same here. I patched StumpWM for NixOS, as I really missed it, and it's been my WM for two years. I switched from XMonad, as I really prefer manual tiling.

XMonad keybindings are great, though. I emulate some in Stump.

This might be an useful source if you need packages for EXWM: https://emacs.zeef.com

So, if I understand this correctly, there are no ``workspaces'', but all X windows become EMACS buffers?

Emacs has this concept of frames. So you have workspaces by switching frame. Super-<number> is suggested binding for that.

But the weird thing here is that text buffers are shared between frames, but X11 buffers aren't. There's a function one can call to move an X11 buffer to another frame.

One nice thing is that it bridges the web behaviour (maybe). Eg editing markdown files and previewing them has the friction of changing windows. EWW is ok but not great. If I can run an x app inside Emacs, that’s better.

You don't need to use emacs as your window manager to run a browser in a buffer, see emacs-application-framework: https://github.com/manateelazycat/emacs-application-framewor...

EAF is also a kind of window-manager, just for PyQt instead of X11. Though, EAF-Component have problaly a bit better integration into emacs. KDE/Gnome-Integration seems to have died with dbus a decade ago.

The issue about Wayland support is interesting reading:

https://github.com/ch11ng/exwm/issues/559

Having a separate window management service is perhaps the greatest blessing of X11. This is one area where X11 offers endless choice, with sometimes dramatic differences between each.

Experimenting with different window managers is something I started to do very early in my linux journey and identified as a clear win.

This is putting a very high bar for me to try anything "wayland", since I'm not particularly fond of sway, won't ever go back to dumbed-down window manager, useless client-side decorations, very questionable input management and lack of pervasive unredirection.

> With 'pure Elisp' I mean no FFI. Most Wayland compositors call low-level interfaces to manipulate graphics, but we can not implement such a compositor since those interfaces are largely absent in Elisp and the performance would be of a great concern. So I tend to make a subcompositor that runs on top of another compositor (mutter for example) to offloads most dirty work and only deals with window management. But even this simplified design can not be realized due to the inability of Elisp to send/receive file descriptors through a socket.

It seems like in this case it's a limitation of elisp, not wayland.

You could argue that with emacs modules nowdays you can implement a full compositor by linking-in parts of wlroots if you really wanted to.

My point is that you don't have to do any of that in X11 since window-management is implemented through a separate protocol and stand-alone process, which makes it much easier to implement.

But how do I launch an application?!

Using emacs' facilities for running child processes. I have

    ;; 's-&': Launch application
    (exwm-input-set-key (kbd "s-&")
                        (lambda (command)
                          (interactive (list (read-shell-command "$ ")))
                          (start-process-shell-command command nil command)))

Edit: There's an example configuration that has this and other bindings: https://github.com/ch11ng/exwm/wiki/Configuration-Example

You can use Rofi, dmenu or a similar application launcher.

Please just give an Emacs OS .

Right the logical next step here is to replace X with emacs.

Have emacs itself provide wayland compositing or whatever within its buffers. Then we're cooking with fire and can just have init (or whatever abomination kids these days have replaced it with) boot right into emacs.

The future!

Reply on news.ycombinator.com