Re: Backtrace printing in batch mode ignores all customizations

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: Paul Pogonyshev <address@hidden>, Emacs developers
>  <address@hidden>
> Date: Mon, 13 Jan 2020 14:23:09 -0500
> 
> Paul writes:
> > Here is a proposed patch that unifies the two print-backtrace-and-quit
> > cases (batch mode and the failsafe). The patch is large mostly because
> > of required reindenting, in fact only 15-20 lines are changed.
> 
> Looks good to me, thank you for doing it.
> Eli, do you think this can go into `emacs-27`?

Yes, I think so.  But I have a question and a request:

> +    (let ((only-backtrace (or noninteractive
> +                              ;; If 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.
> +                              (and (eq t (framep (selected-frame)))
> +                                   (equal "initial_terminal" 
> (terminal-name)))))

Paul said earlier that the latter condition, which tests
terminal-name, is always correct in batch mode.  If that is indeed so,
then why do we need to test noninteractive as well? it's redundant,
no?

And the request is to add a comment explaining the semantics of
only-backtrace.  Not how it is set -- this is clear from the code, --
but what does it mean in terms of the code after that which uses the
value.  Because I don't think the name is descriptive enough, and the
value is tested more than once below.

Btw, I'd be much happier if the condition didn't rely on low-level
implementation details such as the actual name of the initial
terminal, nor on when exactly during startup that terminal gets
deleted.  I think it would be much cleaner to set a variable at the
right place in startup.el (AFAIU, after we call frame-initialize), and
test it in debug.el.  I realize that this condition was copied from
the code we already had in debug.el, but maybe on master we should use
a cleaner solution.

Thanks.

P.S. One other situation where this should be tested is in the daemon
mode.