[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: Wed, 15 Jan 2020 12:34:44 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

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

If for some reason an interactive terminal is created but the
initial_terminal is still used (and is still the currently selected
terminal), we'd then have to tweak debug.el to make sure that it does
use the interactive terminal rather than the dummy one.

Also, what about an emacs-daemon in which an interactive frame has been
created in the past but has been deleted since?

Maybe a cleaner option than the one I suggested would be:

    (defun frame-get-interactive ()
      "Return a frame which supports interaction.
    All tty and GUI frames qualify, but not the frames on the \"initial\" 
    which 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."
      (if (not (and (eq t (framep (selected-frame)))
                    (equal "initial_terminal" (terminal-name))))
        (dolist (frame (frame-list))

-- Stefan

reply via email to

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