[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [External] : Re: Learning Edebug
From: |
Drew Adams |
Subject: |
RE: [External] : Re: Learning Edebug |
Date: |
Sat, 21 Dec 2024 18:44:47 +0000 |
> instrumenting code is basically what you've been
> doing with print statements. When edebug
> instruments the code and inserts its own debugging
> snippets, you can execute the code normally and
> the instrumentation that edebug inserted will call
> the edebug functionality.
In Elisp the equivalent of a print statement
is a `message' call:
(message "foo value at position 42: %S" foo)
You can insert calls to `message' in your code
anywhere, to provide trace-like behavior and
not invoke any debugger.
You can also invoke the (classic) Lisp debugger
by inserting breakpoints in your code anywhere.
These are just calls to function `debug'.
In the debugger, you can use the key `e' to
evaluate any Lisp expression _within the
context of the stack_, i.e., the current
control context.
As a shortcut, you can insert a `debug'
breakpoint that immediately evaluates a sexp
you pass to function `debug' as an argument,
saving you from typing it and hitting `e'.
If you just immediately hit `c', to continue
(exiting) the debugger that was just entered
(or `q' to quit), then This is akin to using
`message' (or `error').
You pass the sexp to evaluate as the second
arg to `debug', using `nil' as the first:
(debug nil (some-expression))
These are _ad hoc_ ways to get info at
particular places. Easy to control (on/off
for particular breakpoints by commenting out
their `debug' calls).
- Learning Edebug, Lewis Creary, 2024/12/19
- Re: Learning Edebug, mbork, 2024/12/20
- Re: Learning Edebug, Eduardo Ochs, 2024/12/20
- Re: Learning Edebug, Joost Kremers, 2024/12/20
- Re: Learning Edebug, Michael Heerdegen, 2024/12/20
- Re: Learning Edebug, tpeplt, 2024/12/20
- Re: Learning Edebug, Joel Reicher, 2024/12/21
- RE: [External] : Re: Learning Edebug,
Drew Adams <=