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: [PATCH] Unconditional quit on SIGUSR2 Date: Mon, 28 Mar 2011 20:37:56 +0200 Message-ID: <83bp0vrszf.fsf@gnu.org> References: <4D90354E.9000704@gmail.com> <4D908F5F.8000303@gmail.com> <4D90C42F.9060500@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1301337522 18261 80.91.229.12 (28 Mar 2011 18:38:42 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 28 Mar 2011 18:38:42 +0000 (UTC) Cc: emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 28 20:38:38 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q4HKi-00019I-13 for ged-emacs-devel@m.gmane.org; Mon, 28 Mar 2011 20:38:37 +0200 Original-Received: from localhost ([127.0.0.1]:54960 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4HKW-0007XU-6w for ged-emacs-devel@m.gmane.org; Mon, 28 Mar 2011 14:38:20 -0400 Original-Received: from [140.186.70.92] (port=43128 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4HKK-0007WR-CG for emacs-devel@gnu.org; Mon, 28 Mar 2011 14:38:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q4HK3-0004S9-BP for emacs-devel@gnu.org; Mon, 28 Mar 2011 14:37:52 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:59810) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q4HK3-0004RW-3r for emacs-devel@gnu.org; Mon, 28 Mar 2011 14:37:51 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0LIS005005I35V00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Mon, 28 Mar 2011 20:37:49 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.126.47.180]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LIS005AX6EZ50B0@a-mtaout21.012.net.il>; Mon, 28 Mar 2011 20:37:49 +0200 (IST) In-reply-to: <4D90C42F.9060500@gmail.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:137790 Archived-At: > Date: Mon, 28 Mar 2011 10:23:59 -0700 > From: Daniel Colascione > CC: emacs-devel@gnu.org > > >> Killing Emacs destroys any transient state. The last-resort-quit > >> approach doesn't. > > > > You originally said "save edits or debug Emacs", see above. > > > > What transient state are we talking about? > > I'm talking about any state not already written out to more permanent > storage --- that includes not only unsaved buffer contents, but tramp > sessions, window configurations, various histories, and so on. Isn't that part of handling a fatal signal? > (Speaking of debugging bytecode, by the way: would it be feasible to > someday provide the ability to step through compiled functions > bytecode-by-bytecode?) I'm not sure I understand what you are suggesting here. What I would love is the ability to "disassemble" a Lisp backtrace, so that any byte codes are converted into human-readable Lisp (or something similar). Perhaps there's already such a thing, who knows? > >> can let users recover work and provide more detailed bug reports, as > >> well as help us ferret out the cause of hard-to-reproduce lockups in > >> font-lock code without having to run under a debugger all the time. > > > > I'd like to hear what work can be recovered this way that is not > > recovered by auto-save at fatal signal time. > > Auto-save doesn't run continuously, and not everyone has it turned on. I meant the automatic auto-save triggered by catching a fatal signal. See emacs.c:fatal_error_signal. > >> This way, we can hope to interrupt runaway font-lock code, and for > >> this application, my proposed approach does indeed work. If I could > >> have implemented this feature without introducing additional > >> machinery, I would have. > > > > What prevents the implementation on the Lisp level of a feature that > > could interrupt a runaway font-lock? > > What Lisp-level method do you propose for breaking out of (let > ((inhibit-quit t)) (while t)) ? This isn't an interesting example. I was talking about font-lock, which I understand was the primary motivation for this patch. Font-lock does not have such useless loops (I hope ;-). I was asking about whatever you had in mind when you wished you could implement such a feature without introducing additional machinery. You tell me.