[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: edebug question - context of calling function
From: |
jan |
Subject: |
Re: edebug question - context of calling function |
Date: |
17 Oct 2003 11:35:57 -0700 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 |
"David Vanderschel" <DJV1@Austin.RR.com> writes:
> I sometimes put a source breakpoint in my code to catch a particular
> error condition. When such a conditional breakpoint fires, the
> actual problem, though recognized in the called function, is often
> attributable to the calling function. What I want to do then is to
> look around at the state of the calling function at the time it
> called the function which invoked edebug. I can instrument the
> calling function; but, when in the debugger, I cannot see how to pop
> the context stack so that I can look around at the variables in the
> calling program. What am I missing?
If I understand you correctly, you want to walk up the stack and look
at the local variable in the functions along the way. I had a quick
look and both edebug and the standard emacs debugger seem to be
missing this feature. However, it may not be necessary because elisp
is a dynamically scoped language, for example:
(defun function1 ()
(let ((a 1)
(b 2))
(list a b (function2) a b)))
(defun function2 ()
(let ((b 3)
(c 4))
(edebug)
(setq a 5
b 6)
(+ b c)))
(function1)
when you hit the (edebug) breakpoint in function2 you can just eval
`a' because it is still in scope. You probably already knew this and
want to inspect variables like `b' which have been shadowed by the let
in function2. In this case, I would just move the breakpoint up to the
calling function and make the condition on it more clever so it only
fires under the circumstances you want.
--
jan