From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Ken Manheimer" Newsgroups: gmane.emacs.devel Subject: Re: blink-cursor-end sometimes fails and disrupts pre-command-hook Date: Mon, 21 Aug 2006 11:31:56 -0400 Message-ID: <2cd46e7f0608210831i24e36726w6d6c0bb789f134d@mail.gmail.com> References: <2cd46e7f0608181530l1c1a18f7k1923f610edf73f59@mail.gmail.com> <2cd46e7f0608201549h35257287y86202066b04b58ce@mail.gmail.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1156174793 1158 80.91.229.2 (21 Aug 2006 15:39:53 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 21 Aug 2006 15:39:53 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 21 17:39:41 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GFBlE-0005fu-CQ for ged-emacs-devel@m.gmane.org; Mon, 21 Aug 2006 17:32:20 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GFBlD-0004CG-On for ged-emacs-devel@m.gmane.org; Mon, 21 Aug 2006 11:32:19 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GFBkx-00049x-7t for emacs-devel@gnu.org; Mon, 21 Aug 2006 11:32:03 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GFBks-00043X-CF for emacs-devel@gnu.org; Mon, 21 Aug 2006 11:32:02 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GFBks-00043E-2z for emacs-devel@gnu.org; Mon, 21 Aug 2006 11:31:58 -0400 Original-Received: from [64.233.182.188] (helo=nf-out-0910.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GFBsH-00044l-AX for emacs-devel@gnu.org; Mon, 21 Aug 2006 11:39:37 -0400 Original-Received: by nf-out-0910.google.com with SMTP id q29so2301432nfc for ; Mon, 21 Aug 2006 08:31:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Iat3apF4O4fDk8jg7TuMLBE99qdvkXJGrXCBLU2Eertf2PoIwI34AuerneE/vny3Rs+MNq8uxdeyP47yLZf9z5wg6vicnFYXlcVF4ARVOhAE6UhoB/XWNJSzd3Y89/Km1WaWGM9+kOc3jurDRyZTzjrEHig7JrFzmRKbSzbs3zs= Original-Received: by 10.49.8.1 with SMTP id l1mr7872809nfi; Mon, 21 Aug 2006 08:31:56 -0700 (PDT) Original-Received: by 10.78.144.19 with HTTP; Mon, 21 Aug 2006 08:31:56 -0700 (PDT) Original-To: rms@gnu.org In-Reply-To: Content-Disposition: inline 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:58643 Archived-At: On 8/21/06, Richard Stallman wrote: > "put them" == put the `(backtrace)' call > "where" == at the point in the code for which you want the backtrace. > > To put in an explicit call to (backtrace) is an unusual technique, but > I don't see why it would not work. Since it outputs to > standard-output, you could save multiple backtraces in one buffer. > > what i want, instead, is the ability to get a stack trace for an error > when i am handling that error, in a condition-case or in the > interactive interpreter. > > Does (setq debug-on-signal t) do what you want? > If not, precisely how does what you want differ from that? it requires user intervention, rather than enbling me to handle the backtrace in the condition-case, or stash the backtrace for later examination by whatever/whoever. this is not a gratuitous concern. i have a condition-case in the post-command hook by which the allout extensions i'm developing cooperate with allout-mode. the condition-case catches any errors, so that it and other stuff on the post-command-hook are not disrupted by errors in my extensions' post-command business. for now i stash the error information in a variable and post a message about the occurrence, but i would much prefer to stash a complete traceback implicating the error caught by the condition-case. that said, i had failed to find/realize that debug-on-signal would cause a debug session at the point of error within the condition case. while not quite what i'm seeking, that will be helpful. is there a reasonable way to substitute a function for the debug session, so it could stash a backtrace and proceed on, rather than invoking user intervention? -- ken ken.manheimer@gmail.com http://myriadicity.net