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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.)
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.
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.
57 comments
[ 3.4 ms ] story [ 119 ms ] threadA true comedy hack could be running and editing files in gvim, but to manage gvim's windows in Emacs.
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)
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.
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.
[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
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.
I can imagine that EXWM eliminates the need for SUPER, which for me would free a modifier pair for a useful LVL3.
I currently have a super on both sides and need to shift super in order to get level 3. Some pedals would be nice.
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.
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.
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.
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.
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.
https://github.com/ch11ng/exwm/issues/559
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.
It seems like in this case it's a limitation of elisp, not wayland.
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.
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!
[1]: https://github.com/ch11ng/exwm
- 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.
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
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.)
If killing Emacs ends the session, that must have a different cause. Killing the WM doesn't usually end the session.
https://tech.toryanderson.com/2020/10/19/emacs-in-emacs-a-tr...
Seems weird that no one would have built a multi-threaded emacs by now.
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.
XMonad keybindings are great, though. I emulate some in Stump.