The Emacs flatpak runs well, but does not provide a command line emacs command, and ignores my .config/emacs files, insisting on creating a .emacs.d folder each time it runs. A command line version is essential for updating some packages, etc. The custom config for doom emacs is also essential to me.
I installed Emacs using rpm-ostree and the command line version runs fine, loading the doom configuration as it should from .config/emacs and .config/doom. But the gui version does not run will with the doom configs - the window is initially black, and it only intermittently accepts keystrokes. If I disable my configs by running emacs -Q, the window opens and responds fine, there’s just no doom goodness.
Normally, emacs will run from the launcher and load the doom configs. It would also run from the command line either in the terminal (emacs -nw), or open a gui window if the bare command is used, and load the doom configs.
Thanks!
After posting, I tried running in a toolbox, but the symptoms were the same.
I also installed Emacs in a distrobox of Fedora37, and the same issues with the gui were there.
I also used flatseal with increasing permissions to the filesystem, but that didn’t help either.
It’s very strange.
Thanks again.
Sadly, I think I just need to go back to Fedora37.
I installed my other drive (with my Fedora37 install), booted, installed updates, and it got an error on boot. Had to revert to the previous kernel from the boot menu, checked for updates and, oddly, everything is up to date.
These are the mysteries I was hoping to avoid by using Silverblue.
Do you have custom fonts in your Doom config? I saw similar behavior across a distrobox, RPM, and flatpak version of emacs 28.2 when my fonts were missing.
If it isn’t your fonts, there might be another issue with your emacs config. My suggestion would be to systematically comment out parts of your configuration until you find the line responsible for causing emacs to not render or respond.
Addendum: This happened to me last week, actually. I was also originally convinced this behavior was a Silverblue issue. Emacs is critical to my workflow so I immediately switched back to regular Workstation Fedora… at which point I saw the exact same behavior. I actually had a few other issues as well, notably wrt rendering LaTeX. With my massive Doom configuration that I had been building over years, I had completely forgotten what dependencies I needed to manually install!
Yes, I do.
I may put the silverblue drive back in and have another look.
I just want something stable that doesn’t break when I update it. I’ve been combing through distros, and it seems there are drawbacks with all of them - they’re either current and fragile, or old, stable, and incompatible.
I feel your pain. I’m getting a renewed appreciation for Windows (especially related to graphics support), but I may be going a bit overboard. Debian (too out of date)/Ubuntu (too flaky/flatpak-y)/Fedora (too many updates)? (That’s my current distro dilemma, repeat ad nauseam)
I feel your pain. I’ve also distro hopped a fair bit.
To be fair, though, Emacs is a unique kind of monster no matter what OS you’re using (especially when you have a gigantic config like the one you get from Doom). I wouldn’t use its behavior as a barometer for the stability or quality of whatever OS it happens to be running in.
An easy way to test if Doom Emacs is truly broken or if your config is causing the issues is just to delete everything in your ~/.doom.d directory (but back it up of course). If vanilla Doom loads, then you know that there’s a problem in your custom config. If not, then you know there’s a problem with Doom itself.
If you’re curious, here’s how I finally got Doom Emacs to behave nicely on Fedora Silverblue (tested on 36, 37, and 37 Kinoite).
Install Emacs to the root, rpm-ostree install emacs
Manually install texlive to my user’s home (only necessary if you actually want to export latex / PDFs)
Delete everything in my ~/.doom.d
Install Doom
Systematically put my configuration back in ~/.doom.d to figure out what was causing the window to be unresponsive.
You might look that you can connect your drive externally. So if you want to use it you just have to plug in and boot from it. Just when it really works as you want, you put it back into the computer.
Silverblue is Fedora Workstation made as immutable Image. This means, like android you start an image and mount your writable part around it.
If you brick your working image, you just can boot in a older one.
Silverblue isn’t any more or less stable than Workstation. Each runs the same binaries installed from the same sources depending on the same libraries. The advantage Silverblue has is that updates are have almost no risk because it’s trivial to undo them. I’d call it more reliable, because no matter what kind of updates you make to your system (within reason!), you can always undo them and get back to work.
The way it works is that the entire root filesystem is swapped out during updates. Each time you update Silverblue or any of the packages installed to the root filesystem, you essentially create a whole new root filesystem to boot from, while keeping the old one around. If something goes wrong or you don’t like the changes, all you have to do is run rpm-ostree rollback and reboot your system to get back to where you were.
IMO Fedora and Silverblue are similar in terms of stability. But Silverblue’s ability to sandbox packages gives you an edge when troubleshooting, as you are doing now.
