20 opened frames in 1 week uptime, it is a good time to crash...

i'm just poking fun out of these kinda sad moments, it is not my intention to criticize emacs per se. so chill guys

Perhaps the caption is: "The world if everybody was taught to use Emacs at school" My system rarely crashes. Do you know what causes it?

Indeed people would receive that caption better. The idea was that, if Emacs never crashes, we would be able to constantly take advantage of it and its great ecosystem so the world would be a better place... No idea what causes. I have some 400+ packages, and was using multiple LSP modes, huge org files, 4+ PDFs opened with pdf-tools, 4+ epub files with nov, ... I've tried killing emacs with `SIGUSR2` in the past to get some crash dump, but it never worked.

400 packages? That's impressive. How do you even remember what to use when? I had some issues with Emacs running at 100% processor and started looking at the profiler to figure out what the issue is.

I don't know what sort of unstable build *you're* using, but it's been *years* since Emacs has crashed on me! And I'm running the version that comes with a system *named* "unstable" by its developers (Debian). :)

I assume most of them would be global (or hooked) minor modes, just running in the background?

I am a bit of a minimalist and keep my config as simple as bearable. Having said this, apparently, I have 92 packages installed.

Tramp has entered the chat...

Take a look at `desktop.el`, it's nice and mitigates the downsides of such incidents. It's a built-in for Emacs, assuming you have the sources installed, you can see it via: `find-library desktop`. [Manual page.](https://www.gnu.org/software/emacs/manual/html_node/emacs/Saving-Emacs-Sessions.html)

> And I'm running the version that comes with a system named "unstable" by its developers Unstable refers to the fact that some packages may have breaking changes, so maybe Postgres updates from version 13 to 14 and you have to intervene by running `pg_upgrade`. Nothing should ever crash (hopefully :D)

I've been using emacs daily since ~2007. I can't ever remember it crashing

Mine doesn't crash or hang. Am I doing something wrong?

[deleted]

I don't experience outright crashes that frequently, but what does happen relatively frequently is that emacs will hang to the point where I need to try to revive it with `pkill -SIGUSR2 emacs`.. after which it is usually left in such a broken state that I have to restart it anyway.

Gwash! Had you such a terrible experience with Emacs? You definitely should share - The OS you used it - if you can reproduce the crash - if it happens just in some situations or randomly - maybe a log (dunno if Emacs gives logs) If it’s because of a lisp-macro you wrote, share it with us and we will help fixing that :-)

I crashed yesterday when trying to run describe-keymap on global-map. Emacs segfaulted. Aside from that I don't think a long running emacs is a good idea. The longer the process lives the more fragmented it becomes and even without that since much of the older packages are so stateful, emacs becomes much more unpredictable the longer it's alive. For example I always start a new emacs process (not emacsclient) when I'm about to use tramp because sometimes emacs will just hang, other times it freezes or I hit Ctrl-g repeatedly with no response until eventually it quits the frame and I get that "rejoin, auto save and dump core" message. Emacs is great, but stuff like that really sours the experience IMO.

> 20 opened frames in 1 week uptime 187 buffers, almost 17 days uptime, everything's fine

I had a lot of crashes a few months ago. I desperately wanted to try the xwidget-webkit on Linux. But every time I tried, it hangs. I had to switch to another tty to force quit emacs.

- NixOS with emacs-overlay - emacs-28.0.91 with native compilation - I can't easily reproduce these crashes. Generally Emacs starts hanging after some days in uptime before a full crash. So I'll try leaving the profiling running from now on. Probably related to some package I have installed (if I had vanilla Emacs these crashes would probably never happen, but what is the point of Emacs if we don't extend it? I think it would be great if Emacs isolated the packages somehow so that it would only crash the packages instead of the whole Emacs) - I couldn't find anything referencing Emacs automatically logging crashes. AFAIK only with killing with SIGUSR2 when gets blocked/hangs, but that has never worked for me.

- NixOS with emacs-overlay - emacs-28.0.91 with native compilation I have some 400+ packages installed and many stuff running. So it's probably related to some package I have installed. And if I had vanilla Emacs these crashes would probably never happen, but what is the point of Emacs if we don't extend it? I think it would be great if Emacs isolated the packages somehow so that it would only crash the packages instead of the whole Emacs. I'll leave the profiling running from now on to see what may be causing these issues.

teach me your ways 🥺

I also run nix with natively compiles emacs and Ive never had problems. This is interesting

I got the "spinning umbrella of death" (MacOS) but after removing the gcmh package it all went a way. Its supposed to have gargage collection settings but for me it made it worse (maybe its better for older computers?)

I agree: Emacs without packages it’s not Emacs ;-) My suspicions relies on how NixOS deals with Emacs. 1. Have you tried the same Emacs configuration on another distro? Do you experience the same? 2. Did you install Emacs with nix package manager or did you compile it from the official sources? PS: thank you for the constructive feedback :-) I was tempted to reply bad to your provocative post picture, but I realize a crash is a REALLY frustrating experience :-)

Came here to say this. Only about 75 buffers, but last reboot had 17 days uptime, 25+ not uncommon (mostly depends how often gentoo kernel sources get upgraded). That said, for some reason quitting out of w3m will kill the emacs daemon pretty reliably.

My Spacemacs installation works like the picture, flawlessly between bi-monthly restarts between package upgrades.

I remember trying it in the past, but for some reason it didn't actually remember frames and just opened the buffers and some other strange issues. desktop+ as well. I'll give it another go to see if I have better luck now. Thanks for the suggestion!

Sometimes I have to restart Emacs because it becomes very sluggish, never a crash. I reboot rarely

How are you counting packages?

I admire emacs, but I also want to keep my pinky. Caps lock as control is not the solution and vi mode isn’t either. Vanilla eMacs is a pita. And I don’t want to be the inheritor of a decade of my own eMacs configuration.

I don't remember mine ever crashing. I'm sure at some point in the distant past it has, but I can't remember it.

> Caps lock as control is not the solution But it is the solution to your problem - not only with regards to emacs, but also for everything else

Packages *are* isolated. They are written in elisp, which *should* provide a sandbox. Bad elisp code should throw an error, rather than crashing. (It can hang, but it shouldn't crash.) If it is crashing, the problem is either in the vanilla Emacs part, or the libraries Emacs links to. (Which are technically part of vanilla Emacs.) I would also say: the point of Emacs is to help us get things done. Extending it for the mere *sake* of extending it doesn't seem very useful. But yes, packages often do help us get things done, and I have plenty of them installed myself. A-anyway, my guess would be that your problems related to native-comp, which is still relatively new, and introduces a whole *lot* of new ways for things to go wrong! (*Especially* with that many packages installed.) I'm bracing myself for the day I switch, but I expect it'll be worth it in the long run. cheers

Non standard keyboards with extra thumb keys exist too.

Yeah - it pays off to set things up so there's no particular friction to restarting. A fine example is `consult-buffer` that, in addition to buffers, offers you recentf and project files etc., all in one place. It means summoning some file you don't have to remember whether it's already loaded or change your behavior depending on that. The only negative of restarting for me is the brief pause and flurry of intense activity when first opening a file type or project, most particularly because I'm using `lsp`. That delay is the entire reason I went with an AMD laptop with 8 cores ;).

Definitely agree with the isolation part. I think that was one of the great decisions made for vscode; extensions run in a separate process, so even if theres a bug, at most you experience a little funky behaviour for moment. I'm probably going to get killed in my sleep for uttering a positive word about vscode here. I just think it's important to also acknowledge the things they *did* get right, instead of just hating on electron (fuck electron though) And let's be real, LSP is one of the greatest things that happened to the OG editors in years. A huge part of using Emacs is making it yours. Some people want All the features, others enjoy a simple editor and pride themselves with their package count or start-up time. That great! Stability just shouldn't be what you base that decision on, and I think more could be done on that front instead of always defaulting to point fingers at bloat.

Yeah. I'm much the same. Since switching to Linux and reducing dependencies and using a pretty powerful AMD CPU, I've gotten my startup time to half a second XD. That startup flurry is annoying but since it's only ever on the first file of that type you open I've mostly accustomed to it. Honestly it's not even long enough to be disturbing IMO. For regular programming modes like Python or C it's like half a second. Org-modes the only one where it's noticeably slow (which given how massive it is is sort of understandable). And yeah, consult is amazing. Although I find myself rarely using it as it's probably intended. I still use `find-recent-file` when I intend to find a recent file instead of switch-to-buffer (which I remap to consult-buffer). It's mostly inertia at this stage. The bindings come to mind before anything else so "leader fr" for recentf is instantaneous and using "leader bb" for it would be so weird.

I'd like to know this too. Also GP might have "only" 92 packages because they might have installed all of them on vanilla emacs, instead of using a distro/framework like space or doom. And 400 packages might be because it's either space or doom, likely space, because I think space is bigger than doom.

> I still use same, though I was already used to `recentf` rolled into buffer switching, I keep doing explicit project and bookmark commands when I could just use `consult-buffer`. I love how the friction to getting shit done keeps dropping, between all this and the richness `lsp` brings (and that my Python work is fully type-annotated).

[deleted]

Use the Paradox package https://github.com/Malabarba/paradox

package to count packages, kek