0 
(progn
  (print 11)
  (/ 1 0)
  (print 22)
  (/ 2 0)
  (print 33))

当我在该表达式上按 CMx 时，Emacs 在 (/1 0) 失败时调用调试器。当我按 c 继续而不是 q 退出时，调试器仍然退出而不执行 (print 22) 或 (/2 0)。这里唯一的区别是 c 退出消息

progn: Arithmetic error

什么是 c 和 q 产生很大差异的示例代码，什么时候应该输入 c 而不是 q？

4

4 回答 4

2

差异可以在任何不停止执行的代码中显示出来，即不包含错误（例如，当由 调用时debug）。

于 2013-09-09T08:42:45.393 回答
2

当您使用debug-on-signal. 使用此设置，当发出错误信号时会调用调试器，即使该错误由封闭的condition-case. 在这种情况下c将继续正常执行（即发出错误信号，进而导致处理程序代码运行，然后可以继续正常执行）。

于 2013-09-09T12:42:49.423 回答
0

起初在我看来这是一个非常明显的问题，但在尝试构建一个示例之后，我实际上不得不查看info. 因此，让我总结一下我为自己澄清的内容：

cinedebug与cin不同gdb。这只是在每个断点处停止一秒钟并最终退出。我目前看不出它对任何人有什么用处。等效的是g：这个将继续到下一个断点并停在那里。

这是一个代码示例：

(defun foo ()
  (setq x (loop for i from 1 to 100
             collecting (* i i)))
  (setq y (nth 5 x))
  (incf y))

(foo)

edebug对它：

  1. 将此代码粘贴到*scratch*
  2. 向内移动点foo和C-u C-M-x（调用edebug-defun）
  3. 将点移至yinsetq y和M-x edebug-set-breakpoint
  4. (foo)将点移动到和中的结束括号C-j
  5. 你现在在edebug。在这里，您可以使用快捷方式执行第 3 步，b 而不是M-x ...
  6. 你会发现继续处理SPC很乏味，因为它每次都会遍历循环的每个语句。
  7. 但是，如果您按下g，您将跳过整个循环，最终进入您应该感兴趣的语句。
于 2013-09-09T09:06:16.307 回答
0

另一个区别是关于递归编辑。例如，我可以调用查询替换，然后输入递归编辑，然后键入(/ 1 0)并评估它以进入调试器。现在，如果我按 q，我们将返回顶层并且不再运行查询替换。但是如果我按 c 代替，我仍然在递归编辑中。

更新另一个区别。在调试器中，cis bound to debugger-continuewhich 是一个包装器，exit-recursive-edit 并且q绑定到top-level. 这意味着任何已知的关于exit-recursive-editvs的差异都top-level适用。请参阅递归编辑 - Emacs 手册了解不同之处。

这是一个改编自Recursive Editing - Emacs Lisp Manual中的示例以测试差异的示例。

(defun simple-rec ()
  (forward-word 1)
  (message "111")
  (debug)
  (message "222")
  (forward-word 1))
于 2013-09-09T18:27:21.397 回答