Thanks to EXWM (not mentioned here), emacs has been my literal X window manager for several years. I installed it as a lark, thinking there's no way this will work properly, and just never stopped using it. It's brilliant.
EXWM is great, having the same flow to manage X applications as for emacs buffers is a huge benefit. My only concern is if X11 will be maintained sufficiently into the future to keep using it, currently there is no Wayland support in EXWM.
I don't mean adding threading to existing functionality, and I mostly wouldn't want that. I very strongly prefer emacs' behaviour of queueing up my input events and processing them deterministically regardless of how long it takes to get to them over eg. the JetBrains behaviour where something can happen asynchronously with my input events that can change their meaning depending on when it happens.
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.
I once read a comment here or reddit explaining that the X11 developers moved to Wayland because the X11 code has turned into an unmaintainable mess that can't be worked with anymore. So the reasons are not drama, but just plain old tech debt.
This pre-packaged talking point is often repeated without evidence. The vast majority of X.org developers, including all of the original ones, simply moved to other venues at one point or another. Only a few, like Daniel Stone, have made contributions to both. And it shows in how many lessons had to be re-learned.
What is your evidence? A quick search on google (and the git commits) would show you that many wayland developers are significant former xorg developers.
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.
The drama was mostly over whether or not Wayland should have been the replacement. AFAIU, everyone agreed X11 development was effectively unsustainable or at least at a dead end.
So is X11, though the reference implementation of X11 is also widely agreed to have some serious problems going forward on top of problems with the protocol itself.
You can also use EXWM in Xephyr, so you can have an emacs window with its own controlled windows instead of replacing the whole DE/window-manager. I suppose this doesn't work with multiple frames though.
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.
There is a third option besides replacing your window manager with EXWM or a simpler tiling window manager: to manage desktop windows from within Emacs using your existing X11 window manager or Wayland compositor. This means
- you can position and resize all desktop windows,
- you can switch between Emacs and desktop windows by moving to the left, right, up, down window and
- you can switch back and forth between a named desktop app like Firefox, okular etc. and Emacs.
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.
Having a Lisp system to control your WM/compositor is amazingly empowering, being able to just write some expressions in a buffer and evaluate them on the fly to command windows, apps, keybindings, various settings from sound and display (e.g., color temp) to bluetooth, etc. is crazy awesome.
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.
Automated behaviours like forcing windows to different virtual desktops, modifying windowing behaviour dynamically. Some windows are automatically tiled and others float, etc.
Nowadays there's eat as excellent terminal emulator for emacs, which should replace the need to run external terminals.
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.
I've been an ansi-term user for years (at least on unices, including Cygwin -- if I am forced to use vanilla w32 emacs without a *nix underneath, I will use eshell since I can do more in elisp-land without relying on the shitshow of Windows CLI utils). What are the benefits of eat vs ansi-term, in your opinion?
Also check out the pull requests on that repo if there's something useful - in my case I've been using eat as single terminal instance for a while now - but for replacing stand alone terminals just opening multiple instances via multi-sh or similar isn't really helping for finding the terminals again. My solution was patching eat to allow buffer renames to the terminal title, and for ssh sessions, initially set the terminal title to the host I'm connecting to. Now I can easily find the terminals when switching buffers.
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.
Active exwm user here: I've been using EXWM for one ~1,5-2 years now, and I've configured it pretty much the same way I would love to have the ideal desktop to look like. Minimal, clean, mostly 1 app to focus on, and only 6 virtual desktops I really use.
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!
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 knew someone who ran it with inittab about 3 decades ago, and I very much doubt they were the only one. Emacs could be used as a full-blown OS long ago. It just depends on your needs.
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.
Everything in Emacs exists under the “M-x” keybind (M stands for Meta which is usually Alt on linux and Option on macOS). Because everything you can do is a command (which are just normal functions that have been annotated). Then you have bindings to directly execute those functions instead of going through a prompt.
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.
"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"
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.
I think the most straightforward way to a solid Emacs config is to use emacs-bedrock [1]. It's a very well curated set of packages that enhance the basic experience. It does leave you with plenty of room to fiddle, which is the beauty of Emacs to my mind. I personally use doom because I built my config on it for years, and am happy with my current setup, but if I started again I would go with emacs-bedrock to keep it more minimal.
I felt like that when I started using Emacs, about 25 years ago. It turned out to be worth it, though.
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.
> 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.
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.
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.
The only issue I have had installing VMs on work machines in 20 years of corporate jobs, is licensing questions. Once you prove your licensing is fine then they don't care anynore.
"However, I also don’t like to carry two computers just to jot down personal notes. My remedy is to install a virtualization system and create a “personal” virtual machine."
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.)
Why bother with a VM? When I'm in that situation, I just run my stuff in the cloud and ssh to my machine, alternatively, ssh to my machine at home. Much more minimalist and light weight than a VM as long as your customer allows outgoing ssh and/or connections to a tor/i2p hidden service.
If I'm just jotting down personal notes, I use a pen and a notepad. If I need to transcribe anything into my long-term notes, then I can do that at the end of the day/week/whatever, when I review what I wrote down.
Was just looking at this article yesterday and it inspired me to try it myself. Trying it out today, my fingers became really sore from trying to navigate. Can't imagine using this for a modern development workflow where there's a lot of jumping around. To make it more ergonomic, I'd just be recreating configuration other window managers give me out of the box.
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.
For anyone interested in doing something similar, I highly recommend making the last program in your .xinitrc be a terminal emulator rather than Emacs, that way if Emacs crashes, your other windows will persist.
A VM is displayed as a window on the host OS and Emacs is the window manager within that VM window. What's the difference from running emacs directly as an application on the host?
With Debian as VM this would probably much leaner. Was shocked about current Ubuntu image sizes. E.g. no need to have to download about 500MB of firmware packages with each new kernel.
Ratpoison was always my favourite tiling window manager. There's also a fork called sdorfehs[0] which seems to still be maintained and has a bunch of minor improvements here and there.
Ratpoison seems like one of those pieces of software that you can release without it bitrotting. The manpage also was very comprehensive from what I remember, though I haven't used Ratpoison in a number of years. I wouldn't worry about it breaking or being hard to understand.
A quick google search reveals a lot of (4 years old) youtube videos about it. And although not very meaningful, it's archwiki page was updated a lot in the past 4 years, which means there are still people visiting that page and potentially using it. I've also seen some recent ratpoison rices on the internet.
For support, I'm sure the users in the past has generated enough forum threads for you.
Shawn Betts, the driving force behind StumpWM was also one of the primary developers of ratpoison, according to Wikipedia: <https://en.wikipedia.org/wiki/Ratpoison>
It was released 25 years and four days ago, and is still around. Simple enough to still work I'd bet, though the last official release was in 2017 or so.
Well, if by "operating system" you mean "the layer of the computer that runs my applications" then I'm already there. ;) EXWM + Gnus + misc. other Emacs-based apps FTW.
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.
It looked good at the beginning, but then I found out about its creator - DHH. Not someone I want to support. There are better distros out there (Omarchy isn't a distro btw).
Just effing stop. This shit sounds like Y2K jokes - you're only making a fool of yourself. Lazy setup, zero insight - these jokes void of humor, irony, or even a pinch of truth. Anyone who opens their mouth about Emacs not having decent editing simply has no idea what modern Emacs can offer there. Emacs has hands-down the best plain text editing features unmatched by anything else. Don't even think of challenging me on this sentence; as someone who used a bunch of different editors, I will chew you up and spit you out like a pistachio even before the actual debate.
You might try taking the shells off before chewing them up, then you don't have to spit out crushed shells all over the place (a real turn-off in my book), and can swallow the nuts without lacerating your digestive system.
Thanks to EXWM (not mentioned here), emacs has been my literal X window manager for several years. I installed it as a lark, thinking there's no way this will work properly, and just never stopped using it. It's brilliant.
EXWM is great, having the same flow to manage X applications as for emacs buffers is a huge benefit. My only concern is if X11 will be maintained sufficiently into the future to keep using it, currently there is no Wayland support in EXWM.
Emacs as a Wayland compositor has been shown to be possible. If we eventually get that and threading the future might be rather rosy.
https://emacsconf.org/2022/talks/wayland/
http://perma-curious.eu/repo-ewx/
> If we eventually get that and threading
That's a really big ask. The entire ecosystem around Emacs isn't built for multithreading.
I don't mean adding threading to existing functionality, and I mostly wouldn't want that. I very strongly prefer emacs' behaviour of queueing up my input events and processing them deterministically regardless of how long it takes to get to them over eg. the JetBrains behaviour where something can happen asynchronously with my input events that can change their meaning depending on when it happens.
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.
I've moved to openbsd for this reason. It works well and I don't have to deal with Linux drama. Toxic slug strategy is really working well for them.
I once read a comment here or reddit explaining that the X11 developers moved to Wayland because the X11 code has turned into an unmaintainable mess that can't be worked with anymore. So the reasons are not drama, but just plain old tech debt.
This pre-packaged talking point is often repeated without evidence. The vast majority of X.org developers, including all of the original ones, simply moved to other venues at one point or another. Only a few, like Daniel Stone, have made contributions to both. And it shows in how many lessons had to be re-learned.
What is your evidence? A quick search on google (and the git commits) would show you that many wayland developers are significant former xorg developers.
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.
Openbsd has brought in x11 into their own codebase: https://xenocara.org/
This is why openbsd is great.
I don't care about the drama that happens in Linux land at all.
The drama was mostly over whether or not Wayland should have been the replacement. AFAIU, everyone agreed X11 development was effectively unsustainable or at least at a dead end.
Wayland is not a solution, just a name for some protocols... It's either KDE or Gnome (with it's weird quirks) or some alternative.
So is X11, though the reference implementation of X11 is also widely agreed to have some serious problems going forward on top of problems with the protocol itself.
I'm really happy with OpenBSD also. What is toxic slug strategy?
https://news.ycombinator.com/item?id=45794553
You can also use EXWM in Xephyr, so you can have an emacs window with its own controlled windows instead of replacing the whole DE/window-manager. I suppose this doesn't work with multiple frames though.
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
Me too. Only having issues with floating windows so far.
There is a third option besides replacing your window manager with EXWM or a simpler tiling window manager: to manage desktop windows from within Emacs using your existing X11 window manager or Wayland compositor. This means - you can position and resize all desktop windows, - you can switch between Emacs and desktop windows by moving to the left, right, up, down window and - you can switch back and forth between a named desktop app like Firefox, okular etc. and Emacs.
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.)
do you by chance know of a similar tool but for vim?
AFAIK, not yet. Give it time, seems vim is heading to becoming a similar Operating System to what Emacs is now :)
Having a Lisp system to control your WM/compositor is amazingly empowering, being able to just write some expressions in a buffer and evaluate them on the fly to command windows, apps, keybindings, various settings from sound and display (e.g., color temp) to bluetooth, etc. is crazy awesome.
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.
What are some things you are doing with this capability?
Like I said: "writing my WM config".
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.
Automated behaviours like forcing windows to different virtual desktops, modifying windowing behaviour dynamically. Some windows are automatically tiled and others float, etc.
Nowadays there's eat as excellent terminal emulator for emacs, which should replace the need to run external terminals.
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.
I use vterm which I believe prides itself for being the fastest terminal emulator inside Emacs. The eat README says 1.5 times faster than eat.
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.
I've been an ansi-term user for years (at least on unices, including Cygwin -- if I am forced to use vanilla w32 emacs without a *nix underneath, I will use eshell since I can do more in elisp-land without relying on the shitshow of Windows CLI utils). What are the benefits of eat vs ansi-term, in your opinion?
A few QoL of life commands and better handling of now common escape sequences.
Thanks for the recommendation!
Also check out the pull requests on that repo if there's something useful - in my case I've been using eat as single terminal instance for a while now - but for replacing stand alone terminals just opening multiple instances via multi-sh or similar isn't really helping for finding the terminals again. My solution was patching eat to allow buffer renames to the terminal title, and for ssh sessions, initially set the terminal title to the host I'm connecting to. Now I can easily find the terminals when switching buffers.
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.
tmux?
Active exwm user here: I've been using EXWM for one ~1,5-2 years now, and I've configured it pretty much the same way I would love to have the ideal desktop to look like. Minimal, clean, mostly 1 app to focus on, and only 6 virtual desktops I really use.
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!
>consistently well-running
>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 mean most people accepted multiple crashes or system freezes per day back in the Windows 3 and MacOS 7 era.
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.
This reminds me of "Emacs as PID 1" from a decade ago, to which I sadly cannot find a link anymore
I think this may be it (or something similar).
https://web.archive.org/web/20041030060909/http://www.inform...
http://web.archive.org/web/20070320003919/www.informatimago....
http://informatimago.free.fr/i/linux/emacs-on-user-mode-linu...
I knew someone who ran it with inittab about 3 decades ago, and I very much doubt they were the only one. Emacs could be used as a full-blown OS long ago. It just depends on your needs.
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.
Last time I tried I felt like an old fart using emacs. None of the keys felt natural
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
Everything in Emacs exists under the “M-x” keybind (M stands for Meta which is usually Alt on linux and Option on macOS). Because everything you can do is a command (which are just normal functions that have been annotated). Then you have bindings to directly execute those functions instead of going through a prompt.
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.
"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"
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.
I think the most straightforward way to a solid Emacs config is to use emacs-bedrock [1]. It's a very well curated set of packages that enhance the basic experience. It does leave you with plenty of room to fiddle, which is the beauty of Emacs to my mind. I personally use doom because I built my config on it for years, and am happy with my current setup, but if I started again I would go with emacs-bedrock to keep it more minimal.
[1] https://codeberg.org/ashton314/emacs-bedrock
I felt like that when I started using Emacs, about 25 years ago. It turned out to be worth it, though.
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.
Emacs says it is “self-documenting.”
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.
> 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.
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.
Emacs has a built-in tutorial, have you tried that?
> lazygit has a good 15min vid to get u up to speed
Doom Emacs install from scratch takes less than that.
> None of the keys felt natural
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.
You could try cua-mode, which binds keys to more typical windows/mac/cua contemporary bindings.
> I do not install personal software
To the eyes of his employer installing a personal VM is probably exactly the same.
The only issue I have had installing VMs on work machines in 20 years of corporate jobs, is licensing questions. Once you prove your licensing is fine then they don't care anynore.
Alarm bells will be going off for any company that takes DLP seriously.
"However, I also don’t like to carry two computers just to jot down personal notes. My remedy is to install a virtualization system and create a “personal” virtual machine."
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.)
Why bother with a VM? When I'm in that situation, I just run my stuff in the cloud and ssh to my machine, alternatively, ssh to my machine at home. Much more minimalist and light weight than a VM as long as your customer allows outgoing ssh and/or connections to a tor/i2p hidden service.
If I'm just jotting down personal notes, I use a pen and a notepad. If I need to transcribe anything into my long-term notes, then I can do that at the end of the day/week/whatever, when I review what I wrote down.
(2015) https://web.archive.org/web/20150115000000*/https://www.howa...
Was just looking at this article yesterday and it inspired me to try it myself. Trying it out today, my fingers became really sore from trying to navigate. Can't imagine using this for a modern development workflow where there's a lot of jumping around. To make it more ergonomic, I'd just be recreating configuration other window managers give me out of the box.
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.
I map the arrow keys for switching windows which works quite well for me.
For anyone interested in doing something similar, I highly recommend making the last program in your .xinitrc be a terminal emulator rather than Emacs, that way if Emacs crashes, your other windows will persist.
Something like:
A VM is displayed as a window on the host OS and Emacs is the window manager within that VM window. What's the difference from running emacs directly as an application on the host?
With Debian as VM this would probably much leaner. Was shocked about current Ubuntu image sizes. E.g. no need to have to download about 500MB of firmware packages with each new kernel.
Been a happy EXWM user for a few years now. Really impressed that it comes as a desktop option for GUIX.
GUIX, EXWM, and Emacs are home for now :)
Me: Open browser full screen, vscode selfhosted, termix, tacticalrmm/guacamole. Nowadays I only need a browser.
lol, another side of the spectrum nice setup
Hmm ... I used ratpoison 25 years ago ... is it current/maintained ?
Is there a live release/support/discussion ecosystem for ratpoison in 2025 ?
Ratpoison was always my favourite tiling window manager. There's also a fork called sdorfehs[0] which seems to still be maintained and has a bunch of minor improvements here and there.
0. https://github.com/jcs/sdorfehs
Ratpoison seems like one of those pieces of software that you can release without it bitrotting. The manpage also was very comprehensive from what I remember, though I haven't used Ratpoison in a number of years. I wouldn't worry about it breaking or being hard to understand.
A quick google search reveals a lot of (4 years old) youtube videos about it. And although not very meaningful, it's archwiki page was updated a lot in the past 4 years, which means there are still people visiting that page and potentially using it. I've also seen some recent ratpoison rices on the internet.
For support, I'm sure the users in the past has generated enough forum threads for you.
IIRC StumpWM authors thought of it as a [ideological] successor of ratpoison, no?
Shawn Betts, the driving force behind StumpWM was also one of the primary developers of ratpoison, according to Wikipedia: <https://en.wikipedia.org/wiki/Ratpoison>
It was released 25 years and four days ago, and is still around. Simple enough to still work I'd bet, though the last official release was in 2017 or so.
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.
Next Month: Emacs is my new operating system.
Well, if by "operating system" you mean "the layer of the computer that runs my applications" then I'm already there. ;) EXWM + Gnus + misc. other Emacs-based apps FTW.
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.
How did I immediately know that this person would be a Clojure developer
cool, now, when will emacs get a good text editor?
My Emacs came with a good text editor out of the box. If yours doesn't you may have one of those terrible configurations which uses Evil.
[flagged]
Recommendation makes 0 sense in context.
It looked good at the beginning, but then I found out about its creator - DHH. Not someone I want to support. There are better distros out there (Omarchy isn't a distro btw).
Just a few issues highlighted here:
https://jakelazaroff.com/words/dhh-is-way-worse-than-i-thoug...
https://davidcel.is/articles/rails-needs-new-governance
https://paulbjensen.co.uk/2025/09/17/on-dhhs-as-i-remember-l...
Then don't support him, whatever that means.
[flagged]
[flagged]
Just effing stop. This shit sounds like Y2K jokes - you're only making a fool of yourself. Lazy setup, zero insight - these jokes void of humor, irony, or even a pinch of truth. Anyone who opens their mouth about Emacs not having decent editing simply has no idea what modern Emacs can offer there. Emacs has hands-down the best plain text editing features unmatched by anything else. Don't even think of challenging me on this sentence; as someone who used a bunch of different editors, I will chew you up and spit you out like a pistachio even before the actual debate.
<https://news.ycombinator.com/item?id=20630900>
You might try taking the shells off before chewing them up, then you don't have to spit out crushed shells all over the place (a real turn-off in my book), and can swallow the nuts without lacerating your digestive system.
watch out y'all, we got a real navy-seal-badass over here
Okay, prove me wrong on that claim that Emacs has plain text editing features unmatched by anything else. Give it a try.
Sometimes you just enjoy hard mode.