I'm checking the documentation of the lisp debugger (lispref/debugging.texi) and I ran into some problems.
The first problem is with canceling the effect of debug-on-error by redefining a function. The lisp manual currently explains that I can use debug-on-entry to let a function enter the debugger and that using cancel-debug-on-entry or redefining the function cancels this effect. However, in some cases, the debugger can cancel the effect of redefining a function behind your back. Here is an example: (defun fun1 () 1) => fun1 (defun fun2 () t) => fun2 (debug-on-entry 'fun1) => fun1 (symbol-function 'fun1) => (lambda nil (debug (quote debug)) 1) fun1 is now set up to break on entry. (defun fun1 () 2) => fun1 (symbol-function 'fun1) => (lambda nil 2) Redefining fun1 cancelled the effect of debug-on-entry. (debug-on-entry 'fun2) => fun2 (symbol-function 'fun1) => (lambda nil (debug (quote debug)) 2) debug-on-entry on fun2, caused fun1 to be set up to break on entry as well. This is confusing. The root of this problem appears to be the use of debug-function-list. The debugger uses this variable to store a list of functions that are set to break on entry. debug-on-entry adds its argument to this list and cancel-debug-on-entry removes its argument from this list. Redefining a function does not modify this list, however. So the debug-function-list might not reflect the actual situation. I think that it's probably a good idea to add a function that checks debug-function-list and removes any function that is not set to break on entry and to call this function before debug-function-list is used. I have some problems understanding the code in lisp/emacs-lisp/debug.el, however. There is this function debugger-reenable that sets all functions in debug-function-list to break on entry. I assume that this function is meant to work together with debugger-jump which cancels the effect of debug-on-entry for all functions in debug-function-list but does not modify the list itself. So the next time debug is called (scheduled by debugger-jump by means of debug-frame), it calls debugger-reenable to make the cancellation effect of debugger-jump temporary. This make sense to me. What I don't understand in why debug-on-entry and cancel-debug-on-entry call debugger-reenable as well (thus causing the strange behavior in the example above). What am I missing? A second problem I encountered is with debugger-jump. It is currently not documented in the lisp manual so I'm trying to figure out what it does. From what I understand, it is intended to work just like debugger-continue with the difference that it temporarily cancels the effect of debug-on-entry for all functions. This is not the case however: (defun funa () 1) (debug-on-entry 'funa) (funa) enters the debugger: ------ Buffer: *Backtrace* ------ Debugger entered--entering a function: * funa() eval((funa)) eval-last-sexp-1(nil) eval-last-sexp(nil) call-interactively(eval-last-sexp) ------ Buffer: *Backtrace* ------ When I now press j to invoke debugger-jump, I see: ------ Buffer: *Backtrace* ------ Debugger entered--returning value: nil funa() eval((funa)) eval-last-sexp-1(nil) eval-last-sexp(nil) call-interactively(eval-last-sexp) ------ Buffer: *Backtrace* ------ I would expect a return value of 1. When I press c instead of j (to invoke debugger-continue), the debugger does give a return value of 1. Is this a bug? Lute. _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
