[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: Eli Zaretskii
Subject: Re: Backtrace printing in batch mode ignores all customizations
Date: Wed, 15 Jan 2020 19:54:48 +0200

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Wed, 15 Jan 2020 12:34:44 -0500
> > 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)

How can this happen?  The code which creates the interactive terminal
immediately proceeds to delete the initial one.

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

What does the code do now in the daemon?  That was one of the
questions I asked before.

Anyway, with the variable I propose, we can reset it again (e.g., in
server.el) once there's no interactive frames.

But I don't want to argue about this any further, it doesn't seem to
be worth our time.

reply via email to

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