Eli Zaretskii <address@hidden
> schrieb am Di., 22. Dez. 2015 um 17:11 Uhr:
> Cc: address@hidden, address@hidden, address@hidden,
> From: Daniel Colascione <address@hidden>
> Date: Mon, 21 Dec 2015 22:14:38 -0800
> And even if it were OK for (say) 'cat' to dump core due to
> > stack overflow in a typical environment (which it's not), Emacs is more
> > important than 'cat', because people use it as an interactive text
> > editor and do not want to lose their work.
> >> we already crash if we overflow the stack while we're GCing.
> > If so, that's a bug that should get fixed. It's not an excuse to
> > introduce similar bugs.
> > Really, the idea that it's OK for Emacs to crash is a nonstarter. Emacs
> > should not crash.
> Ideally, we wouldn't have bugs. But we do, and when we hit them, we
> should crash reliably and deterministically if we can't recover
I'm sorry, Daniel, but that kind of philosophy is a non-starter with
Emacs. Saving the user's work even in some cases is much better than
not saving it at all. And the current scheme is quite reliable, it
works in many scenarios, though not all of them.
As for bugs that cause fatal errors, Emacs always tried to catch them
and at least auto-save.
IIUC this code (terminate_due_to_signal) already auto-saves without calling Lisp (or module) code, so this should be usable. We just need to make sure that module code is not run after a stack overflow. Would it be possible to chose this path if a module function is running?