Lisp debugger problems.

[Lute Kamstra]

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.