From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: John Wiegley Newsgroups: gmane.emacs.devel Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc. Date: Sun, 03 Jan 2016 13:45:15 -0800 Message-ID: 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Trace: ger.gmane.org 1451857548 7661 80.91.229.3 (3 Jan 2016 21:45:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Jan 2016 21:45:48 +0000 (UTC) Cc: Eli Zaretskii , Paul Eggert , Emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 03 22:45:35 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 1aFqT1-0000ZG-FE for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 22:45:35 +0100 Original-Received: from localhost ([::1]:43040 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFqT0-00044C-W1 for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 16:45:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49439) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFqSs-00043g-QL for Emacs-devel@gnu.org; Sun, 03 Jan 2016 16:45:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFqSn-0005UY-Ue for Emacs-devel@gnu.org; Sun, 03 Jan 2016 16:45:26 -0500 Original-Received: from mail-pf0-x233.google.com ([2607:f8b0:400e:c00::233]:34447) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFqSn-0005UJ-Mu; Sun, 03 Jan 2016 16:45:21 -0500 Original-Received: by mail-pf0-x233.google.com with SMTP id e65so138690439pfe.1; Sun, 03 Jan 2016 13:45:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:in-reply-to:date:message-id:references :user-agent:mail-followup-to:mime-version:content-type; bh=w55w+aQf16oTkvXCspcjsJRlOT62bLj+7fY0sRHfbPw=; b=dmcdxpLNttHmzEHSf7IG8fXfttFZuLbiqDelMsR1JPCeVTup6zZsmU3rlLL12U4gec kcNR48HSo5D9qehM9EsuzBMsu3LVRn0HV5jeJgnaXojfLZoy0PxKu2XRxIsY4t6E3VqM OO8oB1xmu4YHwnbXtecfNLYfkAqJSgg32ESVrnSmAVSA/2PkcolOM1aKFCoKFo0nIeuT aYS62SZuUDc9jdpkPhLWjxtMEz+TNK5gtZX5tAW2hNFgIEei+r36wjZuNtQzfxNaz/uc mkMOTDp7oa6w1KLrd+AYUUgd6atc06tddpi8JfY7HPWM4QyfXHzwE49tIgdeRDL4S24J K1lw== X-Received: by 10.98.72.199 with SMTP id q68mr123140737pfi.140.1451857521059; Sun, 03 Jan 2016 13:45:21 -0800 (PST) Original-Received: from Vulcan.local (76-234-68-79.lightspeed.frokca.sbcglobal.net. [76.234.68.79]) by smtp.gmail.com with ESMTPSA id f12sm54151494pat.20.2016.01.03.13.45.20 (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 03 Jan 2016 13:45:20 -0800 (PST) X-Google-Original-From: "John Wiegley" Original-Received: by Vulcan.local (Postfix, from userid 501) id 59CA212001091; Sun, 3 Jan 2016 13:45:19 -0800 (PST) In-Reply-To: <56899278.9000007@dancol.org> (Daniel Colascione's message of "Sun, 3 Jan 2016 13:28:24 -0800") User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.5 (darwin) Mail-Followup-To: Daniel Colascione , Eli Zaretskii , Paul Eggert , Emacs-devel@gnu.org X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400e:c00::233 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:197509 Archived-At: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable >>>>> Daniel Colascione writes: > Ideally, Emacs would, on crash (and after auto-save), spawn a copy of its= elf > with an error report pre-filled. Fork and exec work perfectly fine in sig= nal > 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 t= hat > 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 pr= ess 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 us= ers > 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 approac= h. 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 handl= er 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, af= ter 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 t= ell 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. =2D-=20 John Wiegley GPG fingerprint =3D 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGcBAEBCgAGBQJWiZZrAAoJEMFE2PTxn+YwRx8L/1e3uSt6HCyjUKQUkqIp6t2u 7wAFV182axgXY3zZrfBoDO9I1N3ga4p0G72vBUMzVXhek4rUVZwMnyoOI8oPO/lq dShGZi0cDnGkthGMeQHK3bD0pqzeHZ4u8n4XqGhHDn0EEROCvXEKaYuWisOMMda8 RJpIzo/9hmFFNTmEFmgIFuMp10zhG0SKow7p2U4fZNaFRyEQ389qdve5BcAK1JEC P1vcl9Yk+ifBVfr3MXovpUCqyC2t3QBnQd+hMawxxlACg0Lv9koYyKrFbRHZkyB4 ad893Mypz+txD5vAm8byeDloVVFg6pMNDlYypUr5CzVvfdkaUzEcamvNk65TBAJB Vfb4XqAAHztW5XFx1JR4lO7dLSalFk4UYbwL/dOnk5auYI7IxuZYC5rk7hvL79Nb suWeqfq2nL1iiwCmlOy0cFxhc7Y+UyLGkn73QJo9SRi4xDjZiwFuf9FFfTTFvfax Bs9I+qGckhbXDDp98N7q5OV7qKGVrCE2cUjab9QlXg== =a7wc -----END PGP SIGNATURE----- --=-=-=--