Dont. Emacs is there to be tinkered with, and your cat will break it by simply looking at your keyboard.
I love Emacs. I develop for it, financially support it, live it everyday. The last thing you want is to be stuck debugging your failed desktop session on Tuesday morning at the airport as your wife waits for you to find the tickets.
If you love Lisp, give StumpWM a try. Simplicity, DWM. Simplicity with modularity? AwesomeWM just works.
Keep your Emacs config away from your system packages. The latter should prop up the former, not vice versa
Actually your wife might be happy to know that I have developed some nearly stable Emacs packages that interface with the Sabre system for airline reservations. The only drawback other than stability is that they require a SPARC workstation running a special variant of FreeBSD.
That’s why I have a SparcStation LX. Fits in the carryon for travel much better than a pizza box. Even easier to travel with now that I can use an LCD and don’t need to lug around the ‘ol Trinitron.
With an inverter and a car battery in my backpack I can even show a digital/ on screen boarding pass with a full 8 bits of color.
It was even more impressive if you were accustomed to a one-ton SPARCstation pizzabox with a hulking two-ton 21" CRT on top of it.
(There were soon third-party SPARCstations in normal laptop form factors, but then how would bystanders know you were using a SPARCstation. You might as well put a Ferrari in a Prius shell.)
I've been using EXWM since 2016 and this hasn't been a problem for me. Emacs doesn't just magically break on its own. And even if I managed to break my config without noticing it the fix is just a git revert away.
I used StumpWM for many years before EXWM and I don't see how the config situation is any different.
I have been using it since 2017 and I have no problems to report that were specific to EXWM. I also use EXWM on my work dev machhine and have set EXWM as the windows manager for my kids computers.I absolutely love it. If you want the best experience, I recommend compiling emacs >=29 and configure it for native lisp + tree-itter so that you can get the most from eglot.
I have run into issues with the odd package, but nothing that has ruined my day.
The ultimate Awesome setup has to be that used by Daniel Berg and Julian Assange in The Fifth Estate. Plenty of Lua and Python scrolling frantically but I don't remember seeing any Emacs.
When I got cachix set up in Github CI with my custom emacs package that pre-builds and compiles my configuration including packges, I was as giddy as when I started programming. It's over-the-top, unnecessary, overkill, and an absolute blast. Stuff like this is the reason why I've gotten into this whole thing.
(Also, I think overengineering stuff like this is almost an outlet, which helps me stay pragmatic and goal-oriented at work)
Cool. Can you show how you start an Emacs (i.e., what flags you use) to test whether init.el would load successfully next time an Emacs is started the normal way?
Same(-ish) here. Between git and emacs auto-save, I don't recall the last time my init file failed to load without being able to revert to a previous working version almost immediately.
I use AwesomeWM since forever, with about 12 virtual desktops/workspaces. Nice thing is: it's a tiling WM but I can still put some of the workspace in "floating" mode and they then behave not unlike windows on a regular desktop (which makes some programs happy).
The feature that keeps me is that same client can be tagged in multiple workspaces, and it just exists in different layouts. It's a little buggy in the 4.3 tree, but fixing focus issue in my config was easy enough, that's the cool thing about hackable software.
This feature is the one of the biggest reasons I haven't tried something like EXWM or StumpWM yet. I really like AwesomeWM but can't say the same about Lua.
I was working on fixing some of those bugs last weekend. Can you clarify which annoys you the most so I can add unit test later this evening? tl;dr; The main problem is that the z-index stack and client ordering list are global and this cause changes to one tag to affect another. I am moving those structure into per-tag trees rather than global stacks.
> client ordering list are global and this cause changes to one tag to affect another. I am moving those structure into per-tag trees rather than global stacks.
Yup that was exactly the problem and how I solved it too. If I remember correctly if workspace1 has client A and B, and workspace2 has client B and C (B is common), global stack means if I switch from 1 to 2 while focus was on A, while in 2 if I ever switch focus to B, then I when I come back to 1 I would find that focus moved from A to B, which can be annoying.
While I have you here, do you think 4.4 is still years away? Is there an ongoing documentation of API changes?
> While I have you here, do you think 4.4 is still years away?
I/we were never very fond of releases to be honest. All it does is to fragment the number of version in the various LTS distribution, which makes support a pain (vs "the official version" and "git-master"). Also, I don't have that much time these days, so getting a release out is impractical. I am aiming for the Ubuntu 24.04 cutoff for packages.
> Is there an ongoing documentation of API changes?
`git log` ;). But also, just compare the official release doc with the development one. There's over 1k changes. The largest one being the documentation itself. Then a rewrite of the notification and wallpaper APIs are also rather large improvements. Everything is backward compatible, so there should not be any nasty surprises.
> Yup that was exactly the problem and how I solved it too. If I remember correctly if workspace1 has client A and B, and workspace2 has client B and C (B is common), global stack means if I switch from 1 to 2 while focus was on A, while in 2 if I ever switch focus to B, then I when I come back to 1 I would find that focus moved from A to B, which can be annoying.
Annoying, but also like >10k lines of code/tests/doc to "fix". It will take a lot of effort to get this PR merged without behavior changes or regressions... That global stack goes back 15 years and everything depends on it's exact behavior. It's as ossified as it gets.
Even though I still use X11, my concern with AwesomeWM is there seems to be no path forward to Wayland, which will eventually eclipse X to the point that distros stop supporting it.
Distros (especially those based on Debian and Arch/AUR) package all sorts of weird obscure stuff, the chances of not packaging Xorg are kinda low.
And if some do drop it and you don't want to switch to a distro that still has it, you can always compile and install it from source, it isn't that much of an issue. If said distro has XWayland (which is much less likely to be removed) it'll already have most of the libraries available.
Wayland works fine. I have been using Sway for years now without issue. It is also more secure[1], maintained[2] and even works with NVIDIA's proprietary driver. [3][4].
It also isn't the antiquated piece of crap that X11[5] is, which has trouble with things like mixed DPI, and other modern features that Windows and macOS do completely fine without "tweaking" [6].
If Wayland did not exist I would not be using Linux on a desktop. The "screen tearing" with X11 when using a compositor was painful.
Mixed dpi works fine under X and tearing is trivial to avoid.
Meanwhile under every other Wayland compositor other than KDE apps using XWayland are at best an unusable blurry mess.
Kde alone actually handles high and low dpi monitors plus xwayland acceptably and at least under void it's Wayland session is buggy affair still.
As far as sway in addition to being useless for mixed DPI plus XWayland it silently fails to start with Nvidia hardware unless you pass special arguments and modify the kernel command line which just looks to normal people like totally broken. We are talking about the party with >80% of the discrete GPU market.
Then there is zoom screen sharing the fix to make it work with Wayland theoretically came out 4 days ago and is probably still a crap experience.
You will probably suggest getting rid of all XWayland using apps,Nvidia, and zoom but this isn't how people actually use platforms.
If something is supported and available it becomes part of people's expected workflow and people who get a frozen back screen don't throw away their workflow,convince their employers to drop zoom, or go shopping for a GPU they don't use the thing that makes their screen turn black.
Zero fucks are given regarding whose job it is to fix it or whose "fault" it is because nobody cares about plumbing they care about apps and hardware support.
The alternative is like picking an author based on his choice of word processor instead of his work.
People have been calling criticism of Wayland FUD for a decade. For most of that period the actual experience using existing hardware and apps has been pretty bad. The gap between proponents vision and users actual experience is especially large when user uses old stable software and proponents use very recent versions.
This means proponents have taught users they are full of shit and Wayland sucks. This will persist even when all issues are well addressed on versions of software actually used by the majority of people.
Nvidia should just support the goddamn kernel if it wants to have working software on top? Wayland hasn’t hardcoded AMD or whatever, it relies only on the standard kernel APIs for managing buffers for display. You know why your nvidia card works with Xorg? Because you use a proprietary binary patch inside your xserver for it..
Again no user should give even one fuck. Here is the user experience of installing an X11 environment. Install in package management GUI or CLI based on user preference. Log out. Click little icon on login screen select environment. Login.
Lets install say sway. When we click login it silently fails and returns to the login screen. Running it manually at a tty which a user will never do reveals that the dev wants users to pass an argument --unsupported-gpu to acknowledge that he isn't interested in bug reports from you even unrelated to nvidia. Instead of informing you of this the developer has from the perspective of the user just silently crashed and exited. If you decide to debug this you will run into other issues like an invisible mouse cursor this is solved by setting a variable in the environment.
From a user experience perspective this is complete nonsense. The arguments needed to start a functional environment were known from the start but users are required to each go on an online scavenger hunt to discover them.
Your not entitled to the developers time but the user experience I'm used to as a user is that projects take bug reports, and respond if they have time, fix them as time goes by when they can. My normal experience isn't that the dev will insert idealogically motivated crashes into my workflow and make me pass effectively --fuck-me-no-bug-reports-for-you-jerk. I'm not entitled to him running his project differently but I don't know why I would use anything from such a project.
> When we click login it silently fails and returns to the login screen
That’s just your distro of choice fucking up the packaging, or you having installed some special display manager that handles it bad. If anything, xserver is/was a huge pain in the ass to start properly, and sway will just properly startup from console N.
If you want a 100% works suckless experience, then linux is not for you, period.
Of note Wayland fans always say everyone who has trouble are all holding it wrong. Tail wagging the dog they suggest you should have switched DE, applications, GPU, workflows, everything users actually care about in order to serve something no user has ever cared about...plumbing.
If your not holding it wrong then something else MUST be at fault. Your distro must have fucked up the packaging, your app doesn't support wayland, your GPU's wayland support isn't up to snuff. Again users don't usually hire a programmer to figure out which piece of software is to "blame" nor care.
If you have a little red switch and you toggle it to the left and everything works and you toggle it to the right and nothing does most people are going to toggle it right. People have more important shit to do than figure out why toggling it left makes their lives suck.
Look at this exact example with you positing a wholly fictional distro packaging or display manager problem to paper over the fact that sway is literally designed to crash at the login screen if you use the GPU with >80% of the discrete market share.
Nope. In order to start sway while running the nvidia driver you must run
sway --unsupported-gpu
If you try to run it without that option it silently fails at any login screen. If you run it at the console you will note it TELLS you to run it with that option. This means the developer has detected what needs to be done to start a session and is silently telling you to go fuck yourself. There is no argument that every distro ought to exec a wrapper script that tests if you are running nvidia and if found pass --yes-I-understand-fuck-me-sideways when the net effect would be to replace the body of the if statement that already exists in the devlopers code and more to the point I don't think anyone has. You may note here is the default desktop file as provided by the project.
100% my experience as well ! a Few times a year I try to move to Wayland on my modest old Asus laptop with NVIDIA 950M chip.
Either I spend the day with black screens and weird fixes that I had to google on my phone. Or if Nvidia is working there is at least two other things broken, which never seems like an easy fix. Zoom, tearing, dpi etc.
I'm sure you experience are different than mine, but currently these are the problems I have with Wayland and the not have with Xorg.
One can say the same about your post being FUD against Xorg.
For example that first Phoronix post is about RedHat's official stance on Xorg support not about everyone else, other developers still work on it. In fact just a couple of months ago someone implemented tear-free mode in the modesetting driver which would address your issue with "screen tearing".
You can easily check that by looking the xserver commits, it isn't like they are hidden.
The TearFree stuff was added by Sultan Alsawaf who doesn't work at RedHat (though note that above i wrote that this is the official RedHat position, that doesn't mean people from RedHat cant still contribute to the xserver).
I just recently had to switch from a wayland WM (Hyprland) to an X11 due to numerous issues:
- Screen tearing galore (apparently documented but been awaiting a fix upstream for 2+ years)
- Inconsistent input lag across apps. Notably Electron apps, like discord, where the longer I type, the more input lag I experience.
- Blinking apps. When resizing/going fullscreen/refreshing, applications will show desktop wallpaper randomly.
I wish Wayland was more stable for me personally. I want a smooth lagless experience but using a Wayland ecosystem with Nvidia is not where I want it right now...
Read the article! This instance of Emacs runs in a VM he uses for accessing and editing his personal tech notes at work, to provide better separation from his work system. He's not risking much. :)
> morning at the airport as your wife waits for you to find the tickets.
Hah oh the flashbacks. I've literally done this. Except — ironically — I was keeping the tickets in the airline's app.
The airlines app, idiotically, needed the network to fetch the tickets. The airport's network was misconfigured, as many are: it had one of those idiotic "proxy all traffic to the captive portal"¹ things, so the airline app was confused about why its AJAXs weren't returning the right stuff. But in the moment (i.e., TSA) I wasn't grokking that the error from the app was a lie because the network was malicious.
Perhaps Emacs could have saved me…?
(What I do now is open the ticket beforehand and then screenshot it so that it's local. And we also bring paper fallbacks. Paper cannot have it's packets captured.)
¹There's a proper way to do captive portals. This ain't it.
How did "proxy all traffic to the captive portal" MITM the app? Does the app ignore HTTPS errors? Does the app send your PII in plaintext? Does the app not know what are the expected protocols and status code from it's own backend servers?
I once had a ticket on my phone. My phone overheated and crashed just before I reached the ticket checking station at the gate. It refused to start for several minutes, because it was still too hot.
Ever since then, I've been printing out plane tickets...
I used tiling window managers for years (I started with wmii, and I even used ESXM), but now I'm settled on Gnome: Everything works out of the box, and it's mostly keyboard driven. I don't know if there's a good argument for me now to return to tiling window managers.
> I love Emacs. I develop for it, financially support it, live it everyday. The last thing you want is to be stuck debugging your failed desktop session on Tuesday morning at the airport as your wife waits for you to find the tickets.
100%, what possible benefit is there in tightly integrating a bunch of things so if one of them fails the whole house of cards falls down :-), also good luck with having a system so custom you'll have to do all the debugging, patch writing yourself.
It's a "cool idea" but not one you should be doing in practice. I've never really gotten the emacs is "everything". I thought UNIX philosophy was to do one thing an do it well.
Yes you may be really clever and be able to do that, but there are only so many hours in a day.
> It's a "cool idea" but not one you should be doing in practice. I've never really gotten the emacs is "everything". I thought UNIX philosophy was to do one thing an do it well.
Emacs isn't a UNIX program at all, philosophically speaking.
I'm curious why you would be fumbling in your computer trying to find tickets.
I do find the plethora of window managers interesting. Is that same level of exploration going to exist in wayland? My understanding was that the job of a window manager is very different in that world.
> I'm curious why you would be fumbling in your computer trying to find tickets.
I mean, it's certainly a joke, but because jokes are always better explained (/s) it's because most airlines offer the option of paperless ticket emails these days, and if you don't have a smartphone, you'll have to bring up the image on a desktop so they can scan it at the gate.
Right, I mostly get that. I have literally never seen anyone use a computer at airport security. As such, the joke falls rather flat. Would be better on a story about using emacs on your phone?
I should have also said I meant my quip mostly in jest, as well. I don't actually question why they would be doing something I know they aren't actually ever doing. :D
- olwm/olvwm: virtual desktops and the 19" SPARCStation 2 monitor was absolutely amazing at the time
- fvwm, fvwm2
- sawmill/sawfish was my intro to programmable WMs. It was great until Gnome gobbled it up as its default WM eventually ruining it
- GWM I believe is actually older than then all of the above but I haven't discovered it until I was looking for an alternative for sawfish
- StumpWM was my introduction to tiling WMs and having a proper REPL to allow modifying it live. I don't think that GWM had a REPL but I might be wrong
- EXWM is where I've been for quite a while now. Folding X window management into Emacs buffer management was just as amazing as olvwm was back in the day.
Regarding Sawfish I know that development continued after the Gnome adventure and I could have stuck with it but "Gnome ruined it" is how I perceived it at the time. I can't remember what the specific issues were that made me look for alternatives.
The parent is just being ridiculous, Emacs of course has undo, auto-save and version control. And unlike in certain modal editors it's pretty hard to do any real damage without touching Control or Meta.
> The last thing you want is to be stuck debugging your failed desktop session on Tuesday morning at the airport as your wife waits for you to find the tickets.
From the point of view of tiling, Sway is an i3 clone for wayland.
For AwesomeWM as a programming sandbox WM, it is much tougher to get something identical. A lot of AwesomeWM work goes into APIs, CI and documentation. Making a scriptable WM using wlroot isn't the end of the world. Making one with mature APIs, backward compatibility, high test coverage, an active userbase large enough to sustain a plugin ecosystem and extensive documentation is much harder.
Making AwesomeWM 100% wayland compatible has been attempted a bunch of time, getting 80% working has been done a few time too, but the last 20% is like 95% of the effort or something and those projects keep stalling. From my side, I put the little free time I have for this into actually realistic features and maintenance work, at least until there's an actual reason to move away from X11. Most users at this point have been using it for years or even over a decade. They want their setup to keep working the next morning over #newshiny.
Thanks for the response, and thanks for all the effort towards an awesome WM :-) I can totally appreciate your priorities.
My use of Wayland (and for a lot of users , I suspect) is mostly just flowing with all the upstream distribution defaults. Do you expect the number of awesome-on-X users to dwindle or continue for the foreseeable future? My main concern with regards to switching to AwesomeWM would be whether I’ll be left stranded if the rest of the Linux ecosystem moves on.
> I’ll be left stranded if the rest of the Linux ecosystem moves on.
There is no such things. Unless they remove xorg from the repository, then it's just an entry in the session login screen as it always was.
> Also, any pointers to the 80% attempts?
Waycooler rewrite 2 and rewrite 3 are close enough. There's some private implementations that are more recent and more complete, but not released and probably wont ever be. Being a FLOSS maintainer these days isn't very enjoyable (disclaimer: opinions are my own), I can relate to their reticence to open the floodgates. There's one based on wlroot FFI floating around on Discord.
Then there's a bunch of doomed attempts by people who just made the same mistakes as the ones before them, but had too much ego/enthusiasm to acknowledge how it was going to end. The problem with Wayland is that it's hype-y. People who fall into the hype tend to fall into all the hyped techs at the same time. Which means shiny Rust frameworks and edgy code generators. Then all those things are dead a couple months later and whatever depends on them also die. The only way a working AwesomeWM Wayland port can be made is using boring old glib event loops and boring old service-client architecture of xorg. Anything else will not be compatible, so the plugins and existing configs wont work, thus nobody will use it even if it was somehow internally usable. People with a lot of time and grand ideas don't tend to like boring/mature/old techs and backward compatibility. I can't blame them either, why would they.
> your failed desktop session on Tuesday morning at the airport as your wife waits for you to find the tickets.
Does Richard M Stallman look someone who cares about your wife getting upset for missing the plane while you fiddle with Emacs? That use case of Emacs enabling you to browse the web (accessing the airline’s website which runs non-free software) and check-in so you can ride on an airplane(which also uses non-free software) is not something that in his goals for Emacs.
> The last thing you want is to be stuck debugging your failed desktop session on Tuesday morning at the airport as your wife waits for you to find the tickets.
They should be on your phone or you should use your credit card to print them at the airport. I'm sure there are other examples that make your point though. Yours reminded me of the furniture salesman selling a warranty on a couch by saying it'd cover the cost of getting the blood out, or even give you a replacement, should you sit on a scissors and cut your legs up.
I love Emacs. I develop for it, financially support it, live it everyday. The last thing you want is to be stuck debugging your failed desktop session on Tuesday morning at the airport as your wife waits for you to find the tickets.
If you love Lisp, give StumpWM a try. Simplicity, DWM. Simplicity with modularity? AwesomeWM just works.
Keep your Emacs config away from your system packages. The latter should prop up the former, not vice versa