[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#38927: [patch] Backtrace printing in non-interactive mode doesn't us
bug#38927: [patch] Backtrace printing in non-interactive mode doesn't use cl-prin1 etc.
Sat, 4 Jan 2020 23:01:53 +0100
Backtrace printing in batch mode ignores all customizations, at least:
- all `cl-print-object' overrides (`debugger-print-function');
- `print-level', `print-length' and friends;
The reason is this commit:
Author: Stefan Monnier <address@hidden>
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.
- 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.
Description: Text Data
|[Prev in Thread]
||[Next in Thread]|
- bug#38927: [patch] Backtrace printing in non-interactive mode doesn't use cl-prin1 etc.,
Paul Pogonyshev <=