GNU bug report logs - #44942
28.0.50; Emacs should print a backtrace on uncaught errors in batch mode

Previous Next

Full log

Message #22 received at 44942 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 44942 <at> debbugs.gnu.org
Subject: Re: bug#44942: 28.0.50;
 Emacs should print a backtrace on uncaught errors in batch mode
Date: Mon, 07 Dec 2020 12:42:14 +0200

On December 7, 2020 12:29:16 PM GMT+02:00, Philipp Stephani <p.stephani2 <at> gmail.com> wrote:
> Am So., 6. Dez. 2020 um 18:00 Uhr schrieb Eli Zaretskii
> <eliz <at> gnu.org>:
> >
> > > From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > > Date: Sun, 6 Dec 2020 17:50:17 +0100
> > >
> > > Am So., 29. Nov. 2020 um 16:27 Uhr schrieb Philipp Stephani
> > > <p.stephani2 <at> gmail.com>:
> > > >
> > > Pushed to master as commit 40e11743ca.
> >
> > This is an incompatible change.
> 
> Is it? In other words, do we guarantee that no stack trace is being
> printed if debug-on-error is nil? I'd say that parsing error messages
> is brittle anyway, and we're not obliged to provide stable output

The behavior did change.  Since Emacs doesn't have a formal spec  its long-time behavior is a de-facto standard we should strive hard not to break.  As Stefan just pointed out, this change already broke 2 tests  if we need any proof.

> >  Is there a way to get back previous
> > behavior?  If so, please mention that in NEWS; if not, let's please
> > provide a way to get back the old behavior.
> 
> I'd be OK adding a variable for this, but on the other hand I'm not
> really convinced that this is really a breaking change (see above).

Yes, we do need to be able to get back the old bdhavior.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.