I wrote some LISP code that was wrong because I was trying to pop a cons twice:

(let ((pair '("a" . "b")))
  (let* ((a (pop pair))
     (b (pop pair)))

Evaluating this in the *scratch* buffer showed setq: Wrong type argument: listp, "b" in the mini-buffer. I realized that pop requires a list and thus fails the second time; instead, car and cdr work.

I have Enter Debugger on Error enabled. Why doesn't Emacs enter the debugger to show an approximate location of the error?

1 Answer 1


Like this?


(let ((pair '("a" . "b")))
  (let* ((a (pop pair))
     (b (pop pair)))


Debugger entered--Lisp error: (wrong-type-argument listp "b")
  (setq pair (cdr pair))
  (prog1 pair (setq pair (cdr pair)))
  (car-safe (prog1 pair (setq pair (cdr pair))))
  (let* ((a (car-safe (prog1 pair (setq pair (cdr pair))))) (b (car-safe (prog1 pair (setq pair (cdr pair)))))) b)
  (let ((pair (quote ("a" . "b")))) (let* ((a (car-safe (prog1 pair (setq pair (cdr pair))))) (b (car-safe (prog1 pair (setq pair (cdr pair)))))) b))
  eval((let ((pair (quote ("a" . "b")))) (let* ((a (car-safe (prog1 pair (setq pair ...)))) (b (car-safe (prog1 pair (setq pair ...))))) b)) nil)
  funcall-interactively(eval-print-last-sexp nil)
  call-interactively(eval-print-last-sexp nil nil)

Chances are that the debugger is already active. Look for a *Backtrace* buffer, and check for the square brackets in the mode line indicating a recursive edit.

Just visit the *Backtrace* buffer and quit that debug session, and then trigger your new error again.

You could alternatively C-M-c to exit-recursive-edit, or M-x top-level to exit all recursive edits. For details read C-hig (emacs)Recursive Edit

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.