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

[Ken Manheimer]

On 8/20/06, Richard Stallman <address@hidden> wrote:
>     i would really, really, *really* have liked to backtraces to help
>     track this down, but emacs backtraces are useless for that by design.
>     you have to know where to put them to get the backtrace from an error
>     at that point.
>
> I do not understand that sentence.  What do you mean, "put them"?
> What do you mean by "where"--what is a "place"?

"put them" == put the `(backtrace)' call
"where" == at the point in the code for which you want the backtrace.

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.  i want to be able to examine the backtrace
to help find where/when the error happened, rather than needing to
first know where it's happening and then situate a backtrace call, for
the next time.

in fact, this seems like such a key use of backtraces that i suspect
i'm misreading the manual, and that there is a way to do this that i'm
missing.

>       however, i can't understand not having a mode -
>     eg, with a `debug-on-error' style variable, eg
>     `retain-backtrace-on-error' - for retaining backtraces on any error,
>     to be replaced when the next error happens.
>
> We could do that easily, I suppose, but could you explain
> how it relates to the problem?

it would have been helpful in identifying where the "error in
pre-command-hook: (error invalid timer)" was happening.

as it is, i floundered a lot tracking it down, having to first
identify that the error was happening in the blink-paren-end - if i
could have asked emacs to keep the last stack trace in a variable, it
would have been trivial to idenitify that.  further, i had to remove
blink-paren-end from the pre-command-hook via my emacs rc so i could
run it "manually", with the debugger going, so i could examine the
error condition.

even now, as chong yidong suggests, i need to identify where use of a
timer is going awry, disrupting the blink-cursor dance, so i have to
instrument any possibly related error call that might be happening to
see which one it is, and then examine that context.  (the calls may be
in preloaded lisp, which further impedes the investigation.)  if i
could have emacs give me the stack trace after any error, that would
enable me to unravel these layers of information without digging
through and changing code.

this is not my own idea - python does something very like what i'm
describing.  see http://docs.python.org/lib/module-traceback.html for
the basics.

--
ken
address@hidden
http://myriadicity.net