[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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]