Re: blink-cursor-end sometimes fails and disrupts pre-command-hook

["Ken Manheimer" <ken.manheimer@gmail.com>]

On 8/21/06, Richard Stallman <rms@gnu.org> 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