[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Backtrace printing in batch mode ignores all customizations
From: |
Eli Zaretskii |
Subject: |
Re: Backtrace printing in batch mode ignores all customizations |
Date: |
Tue, 14 Jan 2020 17:41:41 +0200 |
> 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.
- Re: Backtrace printing in batch mode ignores all customizations, Stefan Monnier, 2020/01/04
- Re: Backtrace printing in batch mode ignores all customizations, Paul Pogonyshev, 2020/01/04
- Re: Backtrace printing in batch mode ignores all customizations, Stefan Monnier, 2020/01/04
- Re: Backtrace printing in batch mode ignores all customizations, Stefan Monnier, 2020/01/14
- Re: Backtrace printing in batch mode ignores all customizations, Eli Zaretskii, 2020/01/15
- Re: Backtrace printing in batch mode ignores all customizations, Stefan Monnier, 2020/01/15
- Re: Backtrace printing in batch mode ignores all customizations, Eli Zaretskii, 2020/01/15
- Re: Backtrace printing in batch mode ignores all customizations, Stefan Monnier, 2020/01/15
- Re: Backtrace printing in batch mode ignores all customizations, Paul Pogonyshev, 2020/01/25
- Re: Backtrace printing in batch mode ignores all customizations, Richard Stallman, 2020/01/27
- Re: Backtrace printing in batch mode ignores all customizations, Stefan Monnier, 2020/01/26