* blink-cursor-end sometimes fails and disrupts pre-command-hook
@ 2006-08-18 22:30 Ken Manheimer
2006-08-19 15:07 ` Chong Yidong
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Ken Manheimer @ 2006-08-18 22:30 UTC (permalink / raw)
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))
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: blink-cursor-end sometimes fails and disrupts pre-command-hook
2006-08-18 22:30 blink-cursor-end sometimes fails and disrupts pre-command-hook Ken Manheimer
@ 2006-08-19 15:07 ` Chong Yidong
[not found] ` <87veoo95zy.fsf@furball.mit.edu>
2006-08-20 12:05 ` Richard Stallman
2 siblings, 0 replies; 15+ messages in thread
From: Chong Yidong @ 2006-08-19 15:07 UTC (permalink / raw)
Cc: Emacs-Devel
"Ken Manheimer" <ken.manheimer@gmail.com> writes:
> 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.
>
> 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)
>
> after a bunch of searching, i determined the problem was happening in
> blink-cursor-end running off of the pre-command-hook.
If blink-cursor-end is being run, that means that blink-cursor-start
has been called. If blink-cursor-start completed, blink-cursor-timer
should be non-nil. There isn't a lot of possibilities for
blink-cursor-timer to be nil inside blink-cursor-end.
One possibility is a rogue interrupt handler:
* blink-cursor-end is interrupted before it can cancel
blink-cursor-timer; or blink-cursor-start is interrupted before it
can set blink-cursor-timer
* Something inside the interrupt handler runs pre-command-hook, so
blink-cursor-end runs, and blink-cursor-timer is set to nil.
* Execution resumes. blink-cursor-timer is now nil.
However, I don't know any way an interrupt handler could end up
running a pre-command-hook.
So this is very strange.
^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <87veoo95zy.fsf@furball.mit.edu>]
* Re: blink-cursor-end sometimes fails and disrupts pre-command-hook
2006-08-18 22:30 blink-cursor-end sometimes fails and disrupts pre-command-hook Ken Manheimer
2006-08-19 15:07 ` Chong Yidong
[not found] ` <87veoo95zy.fsf@furball.mit.edu>
@ 2006-08-20 12:05 ` Richard Stallman
2006-08-20 22:49 ` Ken Manheimer
2 siblings, 1 reply; 15+ messages in thread
From: Richard Stallman @ 2006-08-20 12:05 UTC (permalink / raw)
Cc: emacs-devel
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"?
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?
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: blink-cursor-end sometimes fails and disrupts pre-command-hook
2006-08-20 12:05 ` Richard Stallman
@ 2006-08-20 22:49 ` Ken Manheimer
2006-08-21 7:15 ` David Kastrup
2006-08-21 11:13 ` Richard Stallman
0 siblings, 2 replies; 15+ messages in thread
From: Ken Manheimer @ 2006-08-20 22:49 UTC (permalink / raw)
Cc: emacs-devel
On 8/20/06, Richard Stallman <rms@gnu.org> 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
ken.manheimer@gmail.com
http://myriadicity.net
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: blink-cursor-end sometimes fails and disrupts pre-command-hook
2006-08-20 22:49 ` Ken Manheimer
@ 2006-08-21 7:15 ` David Kastrup
2006-08-21 11:13 ` Richard Stallman
1 sibling, 0 replies; 15+ messages in thread
From: David Kastrup @ 2006-08-21 7:15 UTC (permalink / raw)
Cc: rms, emacs-devel
"Ken Manheimer" <ken.manheimer@gmail.com> writes:
> On 8/20/06, Richard Stallman <rms@gnu.org> 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.
(setq debug-on-signal t)
It's not actually a fun setting, since it catches quite a lot, but it
is useful.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: blink-cursor-end sometimes fails and disrupts pre-command-hook
2006-08-20 22:49 ` Ken Manheimer
2006-08-21 7:15 ` David Kastrup
@ 2006-08-21 11:13 ` Richard Stallman
2006-08-21 15:31 ` Ken Manheimer
1 sibling, 1 reply; 15+ messages in thread
From: Richard Stallman @ 2006-08-21 11:13 UTC (permalink / raw)
Cc: emacs-devel
"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?
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: blink-cursor-end sometimes fails and disrupts pre-command-hook
2006-08-21 11:13 ` Richard Stallman
@ 2006-08-21 15:31 ` Ken Manheimer
2006-08-21 17:23 ` Stuart D. Herring
0 siblings, 1 reply; 15+ messages in thread
From: Ken Manheimer @ 2006-08-21 15:31 UTC (permalink / raw)
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: blink-cursor-end sometimes fails and disrupts pre-command-hook
2006-08-21 15:31 ` Ken Manheimer
@ 2006-08-21 17:23 ` Stuart D. Herring
2006-08-22 21:12 ` Ken Manheimer
0 siblings, 1 reply; 15+ messages in thread
From: Stuart D. Herring @ 2006-08-21 17:23 UTC (permalink / raw)
Cc: emacs-devel
> 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?
C-h v debugger
Does that help?
Davis
--
This product is sold by volume, not by mass. If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: blink-cursor-end sometimes fails and disrupts pre-command-hook
2006-08-21 17:23 ` Stuart D. Herring
@ 2006-08-22 21:12 ` Ken Manheimer
2006-08-23 14:45 ` Richard Stallman
0 siblings, 1 reply; 15+ messages in thread
From: Ken Manheimer @ 2006-08-22 21:12 UTC (permalink / raw)
Cc: emacs-devel
On 8/21/06, Stuart D. Herring <herring@lanl.gov> wrote:
> > 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?
>
> C-h v debugger
>
> Does that help?
that was the final piece i needed.
i've just barely started using it, but my post-command-hook has this fragment:
(condition-case failure
[...]
(when allout-widgets-changes-record
(let* ((debug-on-signal t)
(debug-on-error t)
(debugger 'allout-widgets-postcommand-hook-error-handler)
[process the pending changes]
[...]
))
(error (setq allout-widgets-changes-record nil))
and the handler looks like this:
(defun allout-widgets-postcommand-hook-error-handler (mode args)
"Process errors which occurred within the extent of a command hook.
We store a backtrace of the error information in the variable,
`allout-widgets-last-hook-error', unset the error handlers, and
reraise the error, so that processing continues to the
encompassing condition-case."
;; first deconstruct special error environment so errors here propagate
;; to encompassing condition-case:
(setq debugger 'debug
debug-on-error nil
debug-on-signal nil)
(let* ((bt (with-output-to-string (backtrace)))
(this "allout-widgets-postcommand-hook-error-handler")
(header
(format "allout-widgets-last-hook-error stored and posted, %s/%s %s"
this mode args
(format-time-string "%e-%b-%Y %r" (current-time)))))
;; post to *Messages* then immediately replace with more compact notice:
(message (setq allout-widgets-last-hook-error
(format "%s:\n%s" header bt)))
(message header) (sit-for allout-widgets-hook-error-post-time)
;; reraise the error, or one concerning this function if unexpected:
(if (equal mode 'error)
(apply 'signal args)
(error "%s: unexpected mode, %s %s" this mode args))))
i expect this to be very helpful tracking down errors while making my
post-command-hook a "good citizen", unlikely to disrupt the hook due
to uncaught errors.
thanks all for pointing out what i needed to do to record backtraces
at the point of failure.
--
ken
ken.manheimer@gmail.com
http://myriadicity.net
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2006-08-23 14:45 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-08-18 22:30 blink-cursor-end sometimes fails and disrupts pre-command-hook Ken Manheimer
2006-08-19 15:07 ` Chong Yidong
[not found] ` <87veoo95zy.fsf@furball.mit.edu>
[not found] ` <2cd46e7f0608190731j6247e8bbr7f7f8d1ecb6ac3ce@mail.gmail.com>
[not found] ` <87r6zc9475.fsf@furball.mit.edu>
[not found] ` <2cd46e7f0608190805x70bd8715n6f1b552d57a80a5c@mail.gmail.com>
2006-08-19 15:16 ` Chong Yidong
2006-08-19 15:58 ` Ken Manheimer
2006-08-19 16:15 ` Chong Yidong
2006-08-19 16:59 ` Ken Manheimer
2006-08-21 15:36 ` Stuart D. Herring
2006-08-20 12:05 ` Richard Stallman
2006-08-20 22:49 ` Ken Manheimer
2006-08-21 7:15 ` David Kastrup
2006-08-21 11:13 ` Richard Stallman
2006-08-21 15:31 ` Ken Manheimer
2006-08-21 17:23 ` Stuart D. Herring
2006-08-22 21:12 ` Ken Manheimer
2006-08-23 14:45 ` Richard Stallman
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.