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

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

i've been having a hell of a time tracking down a
user-configuration-sensitive blink-cursor error, and can't even report
a case to reproduce it.  i do have a simple change which prevents the
problem and which i think is proper, though i couldn't swear to that.

i'm attaching the patch below.

after my first keystroke in an emacs session, i find the error message
in the *Messages* buffer:

Error in pre-command-hook: (error Invalid timer)

deactivation of the pre-command-hook disrupts my editor session, of
course, disabling all activity on the pre-command-hook.

after a bunch of searching, i determined the problem was happening in
blink-cursor-end running off of the pre-command-hook.  i was unable to
determine the combination of packages and settings from my emacs rc
file necessary to trigger it (and i spent a few hours adding things in
and out, aaargh).

it started happening about a week ago, with upgrade to a recent
version of emacs 22.

one incidental point.

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.  that is terrible - more than half the usefulness of a
backtrace is in pinpointing where an error occurred.  i can understand
not wanting to produce a backtrace on every error, if it's an
expensive operation.  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.   i have no C chops, so
can't implement this, but would love it if someone were interested in
doing so.  (if this kind of thing is already possible, please someone
clue me in, and my apologies for my rant.)

here's the change which prevents the blink-cursor problem.  the
condition is similar to that used in blink-cursor-mode, and i'm pretty
sure is not harmful.  it may be covering over some kind of timing
sensitivity in changes to pre-command-hook, but i've been unable to
track that down.
-- 
ken
ken.manheimer@gmail.com
http://myriadicity.net

--- frame.el	21 Jul 2006 03:42:52 -0400	1.237
+++ frame.el	18 Aug 2006 17:58:18 -0400	
@@ -1308,7 +1308,8 @@
 itself as a pre-command hook."
   (remove-hook 'pre-command-hook 'blink-cursor-end)
   (internal-show-cursor nil t)
-  (cancel-timer blink-cursor-timer)
+  (if blink-cursor-timer
+      (cancel-timer blink-cursor-timer))
   (setq blink-cursor-timer nil))