>>>>> Daniel Colascione <dancol@dancol.org> writes:

> Ideally, Emacs would, on crash (and after auto-save), spawn a copy of itself
> with an error report pre-filled. Fork and exec work perfectly fine in signal
> handlers.

One problem here is that some of us have extensive configurations that load a
great deal of saved state between executions. Spawning a new Emacs just to
send an error report is not something I'd want to see happen.

> But in any case, if we put Emacs into a state where the only thing a user
> can do is save files, why not just save the files? There's no guarantee that
> after a crash that we can even display something.

So, on a detected crash, auto-save all files, and save a text file with the
crash data before exiting? That sounds pretty safe and reasonable to me.

Maybe we could even popup a window to alert the user, and prompt them to press
a key, but the only action will be to exit (unless the user is a power user
and uses recursive edit to attempt to interact with their now-broken Emacs).

> We have no information on how often Emacs crashes in the hands or real users
> or how it crashes. A wait-and-see approach is just blind faith.

I prefer to think of it as data gathering. Accepting the words of one person
about what the future will look like is more in line with the faith approach.
I'm not hearing a chorus of voices against this feature, and I have the word
of other seasoned engineers in support of it.

> One question that neither you, nor Eli, nor Paul have answered is why we
> would try to recover from stack overflow and not NULL deferences. Exactly
> the same arguments apply to both situations.

Why must it be all or nothing? Some is better than nothing. The error handler
can evolve after we know just how useful it is (or whether it is).

Eli, Paul: What do you think about just auto-saving as much as possible,
writing an error trace to a file, and prompting the user to press a key, after
which we abort the running Emacs? This is in line with what many of my OS X
applications do when they encounter a fatal error; they're kind enough to tell
me that it happened, and give me an "OK" button to click before they abort,
but they don't allow me to continue to operate the application in an unknown
state.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2