From (info "(elisp) Instrumenting") :
To remove instrumentation from a definition, simply re-evaluate its
definition in a way that does not instrument. There are two ways of
evaluating forms that never instrument them: from a file with `load',
and from the minibuffer with `eval-expression' (`M-:').
IOW, the easy way is to use C-M-x without prefix ...
Emacs provides a good amount of debugging facilities including M-x toggle-debug-on-error, M-x toggle-debug-on-quit, debug on signal (which can be used by sending USR2 to Emacs from outside), debug-on-entry (of a function), debug-on-message (when seeing a specific regexp match of a message) and finally, debug itself as alternative to instrumenting a function ...
In other words, how do I rescind the directive that causes edebug to enter debugging mode when a particular function is invoked?
You can get this effect without removing instrumentation by setting edebug-initial-mode to go. This way, you will only get stopped in edebug if there is a breakpoint set. As of Emacs 25.1, you can do this quickly with edebug-set-...
Edebug does not support instrumenting code constructed at runtime. If you try to instrument create-function, then the stepping will occur when you evaluate (create-function 2), not when you execute square-two.
Edebug does support instrumenting lambda forms though, so you can rewrite your example using lexical binding:
;;; -*- lexical-binding: t -*-
This is still under development, but in Emacs 26.1 (assuming nothing goes wrong) you will be able to do M-x debug-watch <variable> RET and then any change to the variable will land in the debugger with a backtrace.
You can get the patchset now, at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24923.
Does your patch enable attaching arbitrary code ...
Consensus seems to be that there is no such function built-in.
Since edebug instrumentation data is stored on the target symbols, I have been using the following basic function:
(defun ebpa/edebug-remove-all-instrumentation ()
"Remove all edebug instrumentation by visiting each function
definition and running `eval-defun`."
So it appears that the problem in this case was related to the function being declared in a buffer which doesn't have a file associated with it, thus Emacs was unable to locate the definition. Here's how I discovered this:
I started by looking into the definition of edebug-step-in (I figured out this is the function called in debug mode when I press i for ...
Maybe because it's 2018 now, but in my case,
I only had to turn on debugging like wasamasa suggested:
After this, M-x eval-buffer on my faulty Elisp file
gave context by providing the position of the error,
Debugger entered--Lisp error: (invalid-read-syntax ")")
eval-buffer() ; Reading at buffer position 523
The reason for that behavior is simply that different interactive forms are used in edebug-eval-expression and eval-expression.
You can just override the interactive form of edebug-eval-expression with a part of the interactive form of eval-expression.
(Direct replacement of the interactive form does not work since that two functions differ in the number of ...
You're looking at compiled byte code.
From (elisp) Byte-Code Type:
The printed representation and read syntax for a byte-code function
object is like that for a vector, with an additional ‘#’ before the
Thanks to @abo-abo for the tip to mark the defun first.
Here is a quick way to enable/disable edebug-defun. This uses search-backward-regexp to edebug-instrument or eval the defun or defmacro name correctly, whether it is defined in use-package wrapper or not.
;; Edebug a defun or defmacro
(defvar modi/fns-in-edebug nil
"List of functions ...
You can step into bar (or any function call) with no previous preparation.
eval-buffer (not necessary if everything's already defined).
Invoke C-u C-M-x on foo to instrument it.
Ivoke M-x foo and you'll be taken immediately into edebug, with point right before the (bar) expression.
In edebug, with point right before a function call, you can hit i to ...
You may be able to do this by surrounding definitions of function you want to instrument with (edebug-all-defs).
;; this one is instrumented
(defun foo ()
;; this one is, too
(defun bar ()
;; this one is not
(defun baz ()
Now foo and bar are instrumented, and baz is not.
I found ...
This is Emacs Bug#24750, which is fixed in the master branch (what will become 26.1). For earlier versions, you can add ["using" (symbolp symbolp)] to cl-loop's edebug spec.
(put 'cl-loop 'edebug-form-spec
[[&or "for" "as" "with" "and"]
[[&or "from" "upfrom" "downfrom" "to" "...
There is a similar question there: Running Elisp code when a variable is changed that is closed as a duplicate. The feature is needed there for emacs 24.5.
You get the backtrace at a setq of a critical symbol with the following code.
Execute the code below and (debug-setq 'desktop-dirname) before you load the critical section of your lisp code.
Please note ...
M-x debug-on-entry RET square-two RET
M-: (square-two) RET
Debugger entered--entering a function:
eval-expression((square-two) nil nil 127)
funcall-interactively(eval-expression (square-two) nil nil 127)
call-interactively(eval-expression nil nil)
Use d to step through ...
The REPL interaction mode you are looking for is probably met by ielm (Inferior Emacs Lisp mode).
Here's the start of a solution†:
Open ielm-mode with M-x ielm.
Advise ielm-eval-input to wrap the expressions with edebug-eval-expression:
(defun my/ielm-edebug-eval-input (orig-func input-string &rest args)
"Wrapper function for evaluating expressions ...
You need to apply C-u C-M-x on the definition of a function in order to enable edebug to instrument it for debugging. Your step 3. applies it to the use of the function, which does not do anything useful.
Download the alert.el file and load it with e.g. (load-file "/path/to/alert.el"), then open the file in emacs and navigate to the definition of the alert ...
BTW, while npostavs's solution is the better option for your example, in those cases where you really do need to build the code manually with backquotes (e.g. inside defmacro), you can try:
(defun create-function (number)
(edebug-\` (lambda () (* ,number ,number))))
I found this question because I was having trouble debugging a function that used with-temp-buffer. Using edebug one can press p to temporarily switch to where point is, but this isn't much good because the temp buffer will be gone once edebug is finished.
The easy way in this case is to replace
True to form, I found the answer while asking the question. For anyone else who finds this useful:
If you place this form anywhere in the form that's being instrumented, you'll see point move in real-time as you step through the code. For example,
(defun fancy-stuff ()
Setting edebug options doesn't actually help here. Errors that are listed in debug-ignored-errors are ignored even while executing under Edebug. This isn't mentioned in the manual (as of Emacs 24.5) but it is mentioned in the docstring of debug-on-error (for which edebug-on-error is just a proxy). (I don't understand why debug-ignored-errors has any ...
The usual way is: if it hurts, don't do that.
More specifically, don't "compile + load" the code, but edit the code directly in the Emacs where you perform the tests, and after changing the code just do C-u C-M-x or C-M-x (according to whether the changed code should be stepped or not).
It is not a good idea to add a lambda to a hook if you want to debug this lambda. edebug adds its own stuff so that you cannot easily remove or redefine the function. If you try you end up with two functions in the hook.
Rather define a function such as my-c-mode-common-hook-function and instrument that one.
(defun my-c-mode-common-hook-function ()
I prefer to debug stuff with lispy instead of Edebug, possibly using Edebug for setup.
For me, the biggest advantage is that I can keep the debug state around, without worrying that if I mistype something in Edebug, all the debug context that I've worked on for 10 minutes will vanish and I would have to start from scratch. It's also great for setting test ...