> My Linux + Emacs will remain the same until the heat death of the Universe. The last change was when I had to write an early-init.el file for Emacs 27, the next one will be probably when X is no longer maintained.

Looks like I must be doing something wrong then. Every single time I re-install Ubuntu (and switch to a newer Emacs version), yet another thing in my Emacs config breaks (mostly plugins). To me it's very far from a configure-once-run-forever piece of software.

Try Doom Emacs. You can turn off evil-mode and tweak init.el to get most packages out-of-the-box, even all the language server mode-stuff of VSCode. Check which dependencies are needed and find out how to install them most cleanly, either using distro packages, nix, git, go, stack (for Haskell), npm, and the like. You can reconfigure keybindings so you get cut/copy/paste and everything you need, exactly how you need it. It's going to take a week, but should be stable after that, and you'll realize you could've theoretically done it in hours if you knew enough, which you now do. The Doom-part takes out 95% of needed configuration and makes it more ready-made for usage. It also looks and works like a modern IDE, but you scale it how you like it and have minimal annoyances to turn off.

VSCode has its own shenanigans, of constant updates, configurations, java/scala is a mess to set up, telemetry, proprietary extensions, etc. So deeper work is anyways going to need investments also there, but there's also lock-in to the eco-system and thus less freedom.

I build my Emacs, and my Emacs configuration is relatively simple.

https://github.com/Comevius/dotfiles/blob/master/ABS/emacs/P...

https://github.com/Comevius/dotfiles/blob/master/.emacs.d/ea...

https://github.com/Comevius/dotfiles/blob/master/.emacs.d/in...

Run vanilla Debian. Build emacs from scratch if a new version has something you need, or if you like shiny.

Only fuck with your init.el if you really want/need to.

I've had the same init.el for almost a decade.

> It feels more like renting a computer than owning one.

These corporations don't really want us to own anything. There's always a "license", "terms" or whatever. They're just generously allowing us to use the computers we paid for.

Why is it not OK for companies to ask you to use the software on their terms?

They do with hardware too. Taking a problem with it depends on the end user. Many don't want the knife-seller to dictate how they should use it, what items are allowed to be cut, etc. Once the buyer buys it, they can do anything with it and take full responsibility in doing so.

Because if I buy something then it should be mine and I should be able to do anything I want with it with nobody infringing on my freedom. The total opposite of these terms nobody actually reads where people sign away all the rights that affect the corporation's bottom line for the privilege of being allowed to enjoy the product they paid for and only in the ways the company deems acceptable, a privilege that they retain the right to deny at any time for any reason or no reason.

> On Windows you are always an update away from […] news, the weather, advertisements popping up […]

Block msn.com at the DNS level. That removes almost all of these annoying bugware.

I have a bunch of these rules as part of my pihole blacklist, that works surprisingly well. Adding msn to it was really a visible change when using windows.

What do you know, I tried, and found it to be impossible. You cannot block msn.com at the DNS level, not inside Windows anyway. It's been discussed and everything:

https://seclists.org/fulldisclosure/2006/Apr/509 [RE: Microsoft DNS resolver: deliberately sabotaged hosts-file lookup]

So the only answer is, as pointed out, a pihole or similar outside approach.

Wow, that’s next level evil. I didn’t know.

Not sure who you have been talking to but most Linux developers who I've communicated with have strongly suggested that you do always install updates and don't skip them. It seems it is an equally bad idea to disable automatic updates on Linux as it is on Windows; unfortunately neither of them are formally verified operating systems with any kind of guarantees about correctness and security, so you've just got to keep up with patches.

Linux distros do differentiate between security updates and feature updates. Only the former are recommended to be done automatically.

Microsoft takes the idea of the latter, buries the distinction in the former idea, and shoves "feature" updates down your throat in the name of "security".

> unfortunately neither of them are formally verified operating systems with any kind of guarantees about correctness and security, so you've just got to keep up with patches.

I'm unsure that conclusion follows from those premises, since patches are not formally verified either.

I should have explained it better. Good practice would be to add a regression test when making a bugfix patch, it's not as good as formal verification but it's better than nothing.

I update once a day manually. I build a few packages, but I rely on linux-tkg for the kernel and pull the rest from AUR using git. The Arch Linux package maintainers are very reliable, rolling release is just better when testing is reliable. No big surprises.

Using a rolling release distro usually qualifies as unstable bleeding edge updates I think :)

I guess, and I would not use it on a production server, but on desktop both Ubuntu and Windows can be unstable as well despite spending months instead of weeks or days testing their updates. Arch keeps it simple, there is not much to test, basically just the core, if the kernel, systemd, X, pipewire and gcc or llvm works I can do my job or take care of the rest. Even if they don't I can take care of it. There is not much to it. One can always revert too, the packages are all git based as well. A working system is always a few commands away.

I found annoying to restart all the windows that depend on Emacs window manager (namely EXWM) every time I used to modify its conf. And I modify its conf way more often that I would for any other window manager (because I use it for programming).

Also, the fact that when Emacs freezes, everything else freezes is a huge problem.

A solution would be to use another Emacs within EXWM? That seems unrealistic: keybindings conflicts I guess, and also, then why use EXWM?

Now I'm happy with Gnome (no conf file) + Emacs with 200 lines conf file (which is small). I love that it takes only 1s to restart Emacs when I play with its conf.

I used EXWM for a pretty long while, and I liked it OK, but had similar experiences to you. Eventually moved over to i3wm, and will eventually move over to Sway whenever the chip shortage lets up and I can get a better graphics card.

What I found out:

- i3's config system is pretty extensible, and I was able to port over the majority of the shortcuts I wanted without too much trouble.

- I thought it would be annoying to have configs in two places, but because my Emacs config changes very rarely, and because my i3 config is the same and also changes pretty irregularly, it turns out it's actually not that big of a problem to duplicate setups when I want to add something. Once a setup is stable, optimizing for keeping it in a particular form can sometimes be a lot of work for very little payoff, because you don't spend a lot of time updating it or debugging it in the first place.

- EXWM's keyboard interception (particularly with evil mode) turned out to be not quite as good/low-latency as I needed it to be? And that meant that a lot of the benefits of "one set of bindings/commands everywhere that just works" were a little overstated in practice during daily use.

- On that note, you bump into the problem that stuff like your "save document" shortcut might not actually be very universal, because it's not enough to have your window manager recognize that, you also have to have the program recognize it. And it ends up getting kind of cumbersome to figure out the mappings/scripts you need for each piece of software you have installed (or at least it was for me). Again with the optimization question above, most of the work to keep my keybindings consistent ends up being with applications, not with the window manager.

- Some just general bugginess around some stuff like floating windows that were probably at least partially the result of my config.

- The single-threaded nature of Emacs was a problem, even though people told me it wouldn't be. Freezing your window manager because you run a terminal command incorrectly feels bad.

It was still usable, I was able to get work done on the machine, it was fine and I liked it at the time, I wasn't unhappy. But I've noticed that I spend a lot less time doing maintenance/setup now that I'm using i3, I have far fewer freezes/crashes, and I'm finding that this setup is able to replicate most of the other stuff I care about. There are a few things I miss, but not enough to go back.

i3 or Sway are good alternatives to EXWM, but they are not as customizable. For example I like switching between buffers using autocomplete or cycle between the ones that has the same major mode. I like to toggle certain buffers like Firefox with a shortcut that hides it if it's visible, shows it if it's hidden and opens it if it's not open. I like to filter out buffers that are not part of the current project. All of these work better if applications can be treated as buffers.

EXWM has a few issues like freezing, buffers vanishing into thin air, applications that use multiple windows or fullscreen not being displayed properly. It's developer also vanished around a year ago, it is barely maintained. It is not perfect, but it is powerful. Mucking around in text files, C and shell scripts to replicate my setup would be painful.

It's definitely powerful, but I'll push back a little bit on i3/Sway being really underpowered. There are things I can do in Emacs I can't do in i3. And the reverse is not true, Emacs is definitely capable of a superset of features. However, it's really only the very power-level stuff, the kinds of features you're listing above are all in the category of stuff that I already do in i3.

And what I found is that stuff like "toggling every Firefox window" or "listing all of my open windows and letting me fuzzy-search them" turns out to be about as power-level as I get in practice. So if losing the concept of buffers is the only thing holding you back, I still use "buffers" in i3, I use the same language to think about everything that I used with EXWM. Off the top of my head, some of the stuff I have set up:

- Multiple-key keybindings like I had in EXWM. For example, `alt-spc w d` (command window delete) hides a "buffer" instead of closing it, just like it does in my Emacs config. `alt-spc w /` splits a window right. Modes in general in i3 are abusable in some really interesting ways.

- Buffer fuzzy-search, toggles for application groups, re-grouping applications into different workspaces, etc...

- Window swapping, even between workspaces

- Window splitting/reorganizing using the same keybindings that I used in Emacs. This is a situation where i3 actually has an extremely slight edge because EXWM can't have multiple window views into the same application buffer, so you can't have two windows pointing to the same Firefox buffer. And this problem doesn't vanish outside of Emacs, but working with pure X11 gives you slightly more potential to do weird things around that.

I'm definitely not going to tell someone to switch, if you use EXWM and like it, great, stick with it, I see no problem with that at all. Just that I don't want to scare someone off of trying i3/Sway if they assume they can't script it.

----

The big difference I've found in how I build my config now is that i3 kind of takes the opposite approach to Emacs on interaction with other programs, where instead of having everything bundled inside one config file and pulling state out of those programs into Emacs, in i3 you call out of the config file into normal scripts and those scripts can control i3 with normal messaging or shell commands. So you can still build these really composable setups that are doing very complicated things, it just forces you to be a bit more Unix-y about it.

My personal experience (others may vary):

- The upside to that approach is that i3 is a bit less cumbersome to integrate with other programs, not because Emacs can't, but purely because the syntax is a little bit nicer and I don't need to worry about stuff like threading as much. Big upside in that I can have i3 triggers and commands that originate from other programs. In Emacs I can't really do anything unless Emacs started it or unless I set up a messaging system. It's kind of cool that any extension or script that's running in another program can also call into my i3-config for me if I decide to give it shell access.

- The big downside is stuff like state management, which becomes more annoying because you can't just have a list of pointers to windows that you care about stored in memory. You can do it (session variables, files, etc), but it's the reverse of the problem above, it's just more annoying than it would be in a Lisp repl where you could just make a list. I still haven't really gotten around to building an undo command just because I haven't gotten around to thinking about where I want to store the undo tree.

- And the other (slight) downside is not having nice display prompts built in by default. It's understated in Emacs how nice it is to have one generally agreed-on way to display a list of options on the screen, and Linux in general is missing that kind of universal one-off toolkit for building quick text interfaces/prompts for things. There are a lot of projects that try to fill in these gaps, I haven't found any that I love yet for quick scripting. But that could just be me.

Some of the stuff I miss from EXWM also comes from Emacs being kind of bad at playing with other programs. There's not a lot of good ways for me to add Emacs text buffers to my i3 search commands because Emacs doesn't have any good way I've ever been able find to run a command externally and then pipe the contents of the output buffer back. That means that any functionality I have in Emacs is just kind of locked in there. I can have a keyboard shortcut that opens up an Emacs frame to my TODO list and toggles that on/off, but it has to open up a frame. This has always been weird to me because I'm running Emacs in headless mode, it seems like I should be able to run commands and query text from a buffer without opening a frame.

But all that to say, if all you're talking about is toggling groups of windows or organizing views by project, then that's fine; you can do stuff like that no problem. i3 will give you access to its entire layout tree, so you can traverse it, you can get a list of buffers, and you can do things like edit it, save it to file, reload it. It's not perfect (stuff like merging trees is kind of annoying), but it's pretty usable for most stuff I've tried to do with it. It mostly just comes down to how complicated you want to get with remembering layout and managing state and stuff while you're toggling things.

----

My buffer swap script is:

  #!/bin/bash
  selected_id=$(~/.config/i3/scripts/helpers/buffer-list.sh)
  i3-msg swap container with con_id "$selected_id"
  i3-msg [con_id="$selected_id"] focus

Yes, I know the selected_id line is potentially vulnerable to malicious buffer names.

To split a buffer right and prompt for a new program (same setup I had in EXWM) I have <alt-spc w /> mapped to:

  #!/bin/bash
  selected_id=$(~/.config/i3/scripts/helpers/buffer-list.sh)
  i3-msg mark __current_focused_buffer
  i3-msg split h
  i3-msg [con_id="$selected_id"] move container to mark __current_focused_buffer
  i3-msg unmark __current_focused_buffer
  i3-msg [con_id="$selected_id"] focus

Querying buffers as a helper script: (note the hurdles getting a buffer list from Emacs, and calling into multiple languages to do other parsing just because my Bash-foo is pretty bad):

  #!/bin/bash
  # Get emacs buffers
  # echo "-eval (print-buffer-list)" | nc -U /run/user/$(id -u)/emacs/server 2>/dev/null
  # TODO finish this and do something with it.

  # Get i3 buffers -- I'm using node scripts for some parsing here because it's
  # easier and because I can. Try to stop me.
  i3_tree=$(i3-msg -t get_tree)
  i3_buffers=$(echo $i3_tree | node ~/.config/i3/scripts/helpers/parse-i3-windows.js)

  selected_buffer=$(echo "$i3_buffers" | dmenu -i -b -l 10 -fn 'pango:monospace 18' -p 'Choose a buffer:')
  selected_id=$(echo $selected_buffer | awk '//{print $NF}')
  echo $selected_id

This also can do things like filter out buffers based on titles or their position in the workspace, so basically all the same stuff you would expect from EXWM on that front.

I mentioned in the previous comment, but the other thing I've discovered switching to i3 is that being able to get low-level with some of this stuff and control i3 directly from anywhere turns out to be pretty nice for this kind of setup even if it does mean I'm forced to be a bit more verbose in my code, because my config is pretty set-it-and-forget-it; I add new capabilities only when I need them and otherwise I basically leave it alone. So I'm not really optimizing for being able to re-type this by memory constantly; I rarely edit my config once I have it the way I want it, and then I just have these "operations" like splitting/swapping as helper scripts and if I ever need to use them as part of another command, I call into them.

Thanks for the detailed answer, it was pretty useful to me. I might end up switching to Wayland and Sway at some point.

I want to kind of evangelize that i3/Sway are reasonably powerful, while at the same time being really clear that if EXWM is working for you, it's fine to stick with it, EXWM is great.

Hoping my parent comment doesn't come across as "you need to switch" as much as "if you want to try something else or if you want to move to Wayland, don't let this hold you back."

+1 I worked with someone in the late 1990s who didn’t run X Windows on his Linux laptop, just using Emacs as you do. He went to MIT, so at the time I thought it might be a thing there?

Have you tried the MathPlot shell backend, so you can get colored graphs in the Emacs interactive shell? I like that if I am doing any machine learning via SSH to a remote server.

I run X actually, there is an Emacs package called EXWM that let's you treat any application window as an Emacs buffer. I need X for applications like Firefox, mpv, Wine, Inkscape, LibreOffice, QEMU, mupdf and RetroArch, and I need font rendering.