Since I've upgraded to Ubuntu lucid and emacs23, Emacs p开发者_开发问答ops up the debugger in situations, where emacs22 does not.
For example, when hitting C-c C-c in org-mode, emacs22 simply states can do nothing useful at this location
, whereas in emacs23 the debugger shows up.
Debugger entered--Lisp error: (error "C-c C-c can do nothing useful at this location")
signal(error ("C-c C-c can do nothing useful at this location"))
error("C-c C-c can do nothing useful at this location")
org-ctrl-c-ctrl-c(nil)
call-interactively(org-ctrl-c-ctrl-c nil nil)
That only illustrates the pattern -- the behavior is not limited to org-mode. Occurring every 3 minutes, it really annoys me. How can I prevent it?
I've already tried to stop this using debug-on-error
and stack-trace-on-error
: it didn't work.
Chances are that something is setting debug-on-error after you've configured it.
Some ways to confirm:
Start Org Mode, press C-c C-c to enter the debugger, and q to exit again. Now M-x set-variable
RET debug-on-error
RET nil
RET, and try it again.
Next, try starting emacs with the -q
argument (to avoid executing your init file), and then entering org mode and hitting C-c C-c. This should not trigger the debugger.
You could use M-x rgrep
RET debug-on-error
RET (or maybe debug-on-error t
) on your site-lisp and custom lisp directories, to help track down which library is responsible.
As I could replicate your issue, I've just done this for myself. For me, the culprit was: (load "nxhtml/autostart.el")
. I'm upgrading nxhtml now, which I suspect will resolve things in my case.
Edit: or not.
The current version of nxhtml has moved the statement from autoload.el into nxhtml-base.el. If this is the same culprit for you, you could either edit that file, or make sure that your customisation of the variable happens after nxhtml's autostart file executes.
精彩评论