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 -*-
I would approach this a few ways:
First, you'll want to identify if the problem reproduces in vanilla (i.e. non-configured, no Prelude) Emacs, or with your configurations. As Drew mentioned above, use emacs -Q to launch Emacs without any extra init.el configuration. If it does not reproduce here, then you're looking for a problem with a package or custom ...
I think that there are only the following solutions:
Run tests outside of Emacs from your terminal emulator
Run tests from realgud
Run tests inside Emacs via eshell. But shell output may be corrupted, so this not a good solution
Run tests with pytest-el. It works good, but without autocompletion.
Simply move point in the *Backtrace* buffer to the corresponding line of the frame you're interested in.
examine state of variables
Then press v (debugger-toggle-locals) to show local variables in the frame, or e (debugger-eval-expression) to evaluate an expression in the frame's context. Note that you won't have access to lexical variables when the ...
Try using condition-case-unless-debug instead of condition-case.
You should be able to M-x debug-on-entry either foo or bar in this context:
(defun foo ()
(defun bar ()
(pp-eval-expression '(cons 42 49)))
Note that condition-case-unless-debug just does this:
If you are using messages to yourself while developing then:
That's fine - nothing wrong with using message.
You can also define a wrapper for such uses of message, which respects a global variable you define. That gives you a quick way to turn such messages on/off or otherwise affect them.
An alternative is to use debug, to use the Emacs debugger:
M-x debug-on-entry kill-buffer
That opens the standard Emacs debugger whenever kill-buffer is invoked. It doesn't matter that it's a built-in (primitive, not coded in Lisp).
See the Elisp manual, nodes Function Debugging and Using Debugger.
Short answer : the function backtrace-frame should be what you want.
How did I find this ? Well, here are the steps :
invoke the elisp info manual (my favourite way is C-h r TAB RET), then
search stack in the index via i stack RET.
The first result brings you to (info "(elisp) Internals of Debugger") which mentions backtrace-frame. I think this has all ...
I have used M-x pdb on and off for quite some time now, and while I would love to be corrected on this, unfortunately I don't think it supports tab completion.
I have recently started playing with RealGUD, and if you use this package with ipdb instead of pdb you will get some really nice features including tab completion.
M-x pdb is nice because it is ...
You're probably using an old version of AUCTeX, which had indeed the bug you're reporting: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22417 This was due to an error in the style/subfigure.el file in AUCTeX code and it was raised by a change in the syntax of setq in Emacs 25 (now setq takes an even number of arguments).
If you installed AUCTeX using the ...
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 ...
I had the same problem. Turned out there was a file ~/.emacs-bmk-bmenu-state.el
that still contained the pesky symbol. I moved the file to a save directory, restarted Emacs, and now bookmark+ works again.
Hit C-g when running into the freeze
Don't forget running M-x toggle-debug-on-quit again after successful debugging, it's rather annoying to have every C-g spawn the debugger.
Emacs 27: C-hig (elisp)Backtraces
Debugger mode is derived from Backtrace mode, which is also used to show
backtraces by Edebug and ERT. (*note Edebug::, and *note the ERT manual:
The backtrace buffer shows you the functions that are executing and
their argument values. When a backtrace buffer is created, it ...
s is bound to a new function that was recently added, and indeed it appears to be non–functional. I took a look at the source code, and it does attempt to pull file and line number from the stack frame, but none of the stack frames have any file and line number information :)
It then tries to run hook functions, but the list of hook functions is empty. Those ...
It's possible to format backtraces differently using mapbacktrace with a custom function. One such example is always printing the items as list, I've contributed a patch introducing the debugger-stack-frame-as-list customizable that does that. Check out the implementation of backtrace in Emacs 26.1 or newer.
Here is the beginnings of a list of useful techniques culled from the comments. Please add any others that you find useful by editing this answer:
The elisp analog of sprinkling printfs in a program to show values of variables: (message "Value is %s" whatever).
Using a debugger: possibilities include the Lisp Debugger, and edebug.
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))))
The following answer only addresses the issue of highlighting all the C source code functions in the *Backtrace*. The unmodified stock version of debugger-make-xrefs searches the debugging buffer for matches of (symbol-file sym 'defun), which necessarily excludes the built-in C source code functions. Note that the C source code files must be installed to ...
You could use a custom wrapper script as your -a argument value, but you presumably only want to use --debug-init temporarily, so... just do that.
Kill your Emacs server if it's running, and then restart it with --debug-init.
emacs --daemon --debug-init
Now connect to it as usual.
edit: TomRoche adds the following...
Note that, if this throws an ...