From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc. Date: Mon, 04 Jan 2016 17:29:52 +0200 Message-ID: <838u458irz.fsf@gnu.org> References: <83mvu1x6t3.fsf@gnu.org> <5678CD07.8080209@cs.ucla.edu> <5678D3AF.7030101@dancol.org> <5678D620.6070000@cs.ucla.edu> <83mvt2qxm1.fsf@gnu.org> <56797CD9.8010706@cs.ucla.edu> <8337uuqsux.fsf@gnu.org> <5679DC83.70405@cs.ucla.edu> <83oadhp2mj.fsf@gnu.org> <567AD556.6020202@cs.ucla.edu> <567AD766.3060608@dancol.org> <567B5DAB.2000900@cs.ucla.edu> <83fuyromig.fsf@gnu.org> <567C25B1.3020101@dancol.org> <56892FD6.8040708@dancol.org> <568988EE.3010205@dancol.org> <56899278.9000007@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1451921415 665 80.91.229.3 (4 Jan 2016 15:30:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Jan 2016 15:30:15 +0000 (UTC) Cc: dancol@dancol.org, Emacs-devel@gnu.org, eggert@cs.ucla.edu To: John Wiegley Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 04 16:30:10 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aG757-0004NC-4n for ged-emacs-devel@m.gmane.org; Mon, 04 Jan 2016 16:30:01 +0100 Original-Received: from localhost ([::1]:45414 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aG756-0003d6-G8 for ged-emacs-devel@m.gmane.org; Mon, 04 Jan 2016 10:30:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48082) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aG752-0003cl-BS for Emacs-devel@gnu.org; Mon, 04 Jan 2016 10:29:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aG74x-0000oN-Mk for Emacs-devel@gnu.org; Mon, 04 Jan 2016 10:29:56 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34718) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aG74x-0000oI-JI; Mon, 04 Jan 2016 10:29:51 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3007 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aG74u-0002Nf-CK; Mon, 04 Jan 2016 10:29:51 -0500 In-reply-to: (message from John Wiegley on Sun, 03 Jan 2016 13:45:15 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:197583 Archived-At: > From: John Wiegley > Cc: Eli Zaretskii , Paul Eggert , Emacs-devel@gnu.org > Date: Sun, 03 Jan 2016 13:45:15 -0800 > > 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. Which is why we already do that. See shut_down_emacs. > 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 already do that as well, as part of so-called "emergency exit". See handle_interrupt. > 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). That's exactly the crux of our disagreement with Daniel: we think partial recovery is better (for users) than no recovery, while he thinks that no recovery is better (because it makes the job of debugging easier). > 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? We already do all that, we just don't prompt in most cases. We simply auto-save and then commit suicide. But in the case of stack overflow, we can do better, so we try that as well. > 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. On MS-Windows, when we abort or succeed in catching a fatal signal early enough, we also pop up an abort dialog, which even allows to attach a debugger, not just exit. IOW, all of these reasonable things we already do. The argument is not about them, it's about going some extra mile in the specific case of stack overflow. In that case, we can do better in most cases: avoid crashing entirely, leaving Emacs in a state where the user can shut down the session in a more orderly fashion. Admittedly, this won't work in all cases, but that's not required.