Re: edebug question - context of calling function

["David Vanderschel" <DJV1@Austin.RR.com>]

"Stefan Monnier" <monnier@iro.umontreal.ca> wrote in message
news:<jwvu15yskro.fsf-monnier+gnu.emacs.help@vor.iro.umontreal.ca>...
> > I am familiar with other debuggers which allow you to
> > proceed up and down the stack of call frames, looking
> > at context (including location of the call in each
> > calling program) in a whole hierarchy of calling
> > functions.  I just expected such capability in edebug
> > and was trying to find out how to exercise it.
> > However, I am willing to accept that the capability is
> > not there.

> I don't think edebug has that feature, although I can't think of
> any particular reason why not (as long as the calling function
> you want to look at is instrumented, of course).

I could not think of any such reason either, which is
why I was looking for the functionality.  (I was
instrumenting the calling function.)

> If your calling function is byte-compiled, you can
> improve things a little by using the
> non-byte-compiled version in which case the
> backtrace will give you more than just the calling
> function's name and arguments.  It won't give you
> line numbers, but you should/might be able to
> recognize the calling context enough to figure out
> which of the calls is currently active.

If the calling function has been instrumented, the
point about byte-compiling is moot.  The particular
function which intiated this quest is one in which I
made rather heavy use of CL macros.  The result is
fairly effective obfuscation of any recognizable
context.

I just discovered something which does help:  After
the source breakpoint is hit, I can set a breakpoint
at the end of the called function (or step down to
there).  Then I can step through the return to the
calling function and I _do_ wind up in the context of
the calling program.  So this approach can be used
whenever it is possible to make a return from the
function which recognizes the problem - a possibility
which does exist in the situation which concerned me.
I'd still prefer to be able to get there without executing
the remainder of the called function.

Regards,
  David V.