[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Backtrace printing in batch mode ignores all customizations
From: |
Paul Pogonyshev |
Subject: |
Re: Backtrace printing in batch mode ignores all customizations |
Date: |
Tue, 14 Jan 2020 18:51:31 +0100 |
> 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.
- 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
- Re: Backtrace printing in batch mode ignores all customizations, Paul Pogonyshev, 2020/01/29