Re: Backtrace printing in batch mode ignores all customizations

[Paul Pogonyshev]

I submitted a proposed patch as bug #38927
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38927) a few hours ago
since I thought this thread got ignored. It wasn't enough to just
decouple non-interactive from the "failsafe": it got rusty in the
meanwhile and no longer worked after just adding "(not
noninteractive)" condition. In the patch I didn't try to unify your
"failsafe" mode with non-interactive use, since I don't really know
what you wrote the commit for.

But yes, it does look logical to unify the two cases. I would try
removing the failsafe mode altogether, add sth. like

    (let ((backtrace-to-stderr (or noninteractive
[current-failsafe-condition]))) ...

and replace the two uses of `noninteractive' later with this new
variable. But I don't really know how to test this.

Paul

On Sat, 4 Jan 2020 at 23:44, Stefan Monnier <address@hidden> wrote:
>
> > +    ;; 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 condition seems to always be true when `noninteractive' is t.
>
> The `noninteractive` case is indeed not the one for which this code
> was added.  I guess we can conditionalize it on `noninteractive`, but it
> would be worthwhile looking at the code which causes the
> `noninteractive` case (without the above "failsafe") to dump
> a stacktrace on stderr, to see if the two could be unified?
>
>
>         Stefan
>