Re: Backtrace printing in batch mode ignores all customizations

[Paul Pogonyshev]

> 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?

It is true, but it feels sort of a side-effect to me. You even say
yourself later that you don't like the condition as it goes into
low-level internals. It is extremely non-obvious that it is also true
in non-interactive mode. I think it is better to explicitly have `(or
noninteractive' rather than rely on it implicitly be a subcase of the
second `or' operand (and forget it was meant to be when the second
condition is refactored).

> 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.

How about this?

    ;; When operating without any user interaction, we are going to
print current
    ;; backtrace and kill Emacs, because there is no way to accept
debugging commands.

Paul

On Tue, 14 Jan 2020 at 16:41, Eli Zaretskii <address@hidden> wrote:
>
> > 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.