[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: |
Wed, 15 Jan 2020 17:58:21 +0200 |
> From: Stefan Monnier <address@hidden>
> Cc: address@hidden, address@hidden
> Date: Tue, 14 Jan 2020 15:30:24 -0500
>
> > 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.
Why not?
> The test:
>
> (and (eq t (framep (selected-frame)))
> (equal "initial_terminal" (terminal-name)))
>
> is fundamentally *right*
I didn't say it was wrong, I said it wasn't clean enough, IMO. We
know exactly where in the startup process the interactive frame
becomes available: after the call to frame-initialize. Why wouldn't
it be right to set a flag there which debug.el could test, instead of
testing the above?
> 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).
Even with such a function, my question above still stands.
But anyway, there's no need to wait with installing this on emacs-27
until we end discussing how to make the test cleaner. The cleanup
should go to master in any case.
- 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, Paul Pogonyshev, 2020/01/12
- Re: Backtrace printing in batch mode ignores all customizations, Stefan Monnier, 2020/01/13
- Re: Backtrace printing in batch mode ignores all customizations, Eli Zaretskii, 2020/01/14
- Re: Backtrace printing in batch mode ignores all customizations, Paul Pogonyshev, 2020/01/14
- Re: Backtrace printing in batch mode ignores all customizations, Eli Zaretskii, 2020/01/14
- 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 <=
- 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
- Re: Backtrace printing in batch mode ignores all customizations, Eli Zaretskii, 2020/01/31
- Re: Backtrace printing in batch mode ignores all customizations, Paul Pogonyshev, 2020/01/31