[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: blink-cursor-end sometimes fails and disrupts pre-command-hook
From: |
Ken Manheimer |
Subject: |
Re: blink-cursor-end sometimes fails and disrupts pre-command-hook |
Date: |
Mon, 21 Aug 2006 11:31:56 -0400 |
On 8/21/06, Richard Stallman <address@hidden> 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
address@hidden
http://myriadicity.net
- Re: blink-cursor-end sometimes fails and disrupts pre-command-hook, (continued)
- Re: blink-cursor-end sometimes fails and disrupts pre-command-hook, Chong Yidong, 2006/08/19
- Message not available
- Message not available
- Message not available
- Message not available
- Re: blink-cursor-end sometimes fails and disrupts pre-command-hook, Chong Yidong, 2006/08/19
- Re: blink-cursor-end sometimes fails and disrupts pre-command-hook, Ken Manheimer, 2006/08/19
- Re: blink-cursor-end sometimes fails and disrupts pre-command-hook, Chong Yidong, 2006/08/19
- Re: blink-cursor-end sometimes fails and disrupts pre-command-hook, Ken Manheimer, 2006/08/19
- Re: blink-cursor-end sometimes fails and disrupts pre-command-hook, Stuart D. Herring, 2006/08/21
Re: blink-cursor-end sometimes fails and disrupts pre-command-hook, Richard Stallman, 2006/08/20
- Re: blink-cursor-end sometimes fails and disrupts pre-command-hook, Ken Manheimer, 2006/08/20
- Re: blink-cursor-end sometimes fails and disrupts pre-command-hook, David Kastrup, 2006/08/21
- Re: blink-cursor-end sometimes fails and disrupts pre-command-hook, Richard Stallman, 2006/08/21
- Re: blink-cursor-end sometimes fails and disrupts pre-command-hook,
Ken Manheimer <=
- Re: blink-cursor-end sometimes fails and disrupts pre-command-hook, Stuart D. Herring, 2006/08/21
- Re: blink-cursor-end sometimes fails and disrupts pre-command-hook, Ken Manheimer, 2006/08/22
- Re: blink-cursor-end sometimes fails and disrupts pre-command-hook, Richard Stallman, 2006/08/23