[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Backtrace printing in batch mode ignores all customizations

From: Stefan Monnier
Subject: Re: Backtrace printing in batch mode ignores all customizations
Date: Tue, 14 Jan 2020 15:30:24 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

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

Indeed, it is.

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

Setting a var wouldn't be right.  The test:

    (and (eq t (framep (selected-frame)))
         (equal "initial_terminal" (terminal-name)))

is fundamentally *right*: we want this special behavior when we're
operating in the special dummy(stdin/out) terminal because that terminal
does not offer the usual interaction expected by the normal backtrace
debugger.  So the `noninteractive` is an approximation (and is redundant
for that same reason) whereas the above test is really the correct one.
I agree that it is ugly because (framep (selected-frame)) returns `t`
both for "normal" tty frames/terminals as well as for the special
dummy terminal, so we need to depend on a special terminal name to
distinguish those two cases.

Maybe we can improve the code by introducing a function

    (defun terminal-dummy-p ()
      "Return non-nil if the current terminal is the special initial terminal.
    The \"initial\" terminal is the dummy-terminal used when we don't have
    a real terminal to use, such as is the case in batch mode, or while
    running early-init.el, or while starting the emacs-server."
      (and (eq t (framep (selected-frame)))
           (equal "initial_terminal" (terminal-name)))

and then use it there (and maybe we could then cleanup that function
so it doesn't need to rely on a special terminal name).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]