tags

Backtrace printing in batch mode ignores all customizations, at least:
- all `cl-print-object' overrides (`debugger-print-function');
- `print-level', `print-length' and friends;
- `debugger-batch-max-lines'.

The reason is this commit:

7228488effa78dcb75284cb6d247b24804e0e7f5
Author:     Stefan Monnier <monnier@iro.umontreal.ca>
AuthorDate: 2018-04-02 00:23:20 -0400
[...]

* lisp/emacs-lisp/debug.el (debug): Don't hang upon error in initial-frame.

[...]
+   ((and (eq t (framep (selected-frame)))
+         (equal "initial_terminal" (terminal-name)))
+    ;; We're in the initial-frame (where `message' just outputs to stdout) so
+    ;; there's no tty or GUI frame to display the backtrace and interact with
+    ;; it: just dump a backtrace to stdout.
+    ;; This happens for example while handling an error in code from
+    ;; early-init.el with --debug-init.
+    (message "Error: %S" args)
[...]

The commit added a "failsafe" mode for (quoting) "initial-frame (where
`message' just outputs to stdout) so there's no tty or GUI frame".
This failsafe mode is also erroneously triggered in batch mode. It was
never meant for it: you can see a couple of uses of `noninteractive'
in the next `cond' branch, but execution now never gets to it.

Patch attached:
- don't use this "failsafe" mode when running non-interactively;
- repair for the latest changes in backtrace generation (apparently,
before the buffer was not read-only);
- repair adjustment for `debugger-batch-max-lines' which didn't make
any sense and didn't achieve what it claimed in the comment.

Paul