bug#61847: debug-early-backtrace only works some of the time.

[Alan Mackenzie]

Hello, Eli.

On Wed, Mar 01, 2023 at 15:32:35 +0200, Eli Zaretskii wrote:
> > Cc: 61847@debbugs.gnu.org
> > Date: Tue, 28 Feb 2023 19:52:33 +0000
> > From: Alan Mackenzie <acm@muc.de>

> > The purpose of a backtrace is not to enter a beauty contest.  Rather
> > it's to provide the programmer with as much information as
> > reasonably possible to solve a bug.

> Information that is humanly-readable and understandable, yes.  Not
> just any information.  Showing raw bytes of the bytecode is not very
> useful information, IMNSHO.

In my experience, it is useful.  cl-prin1 outputs essentially no
information at all about compiled functions.  That is not useful.

> Or at least we could make it much more useful, if we really want that
> part to be presented to the programmer.

Debugging used to be done with core dumps.  debug-early-backtrace's
output using prin1 is more useful than that.  And yes, we do want to
present it to the programmer.

> > prin1 by contrast prints the actual contents of the function - its byte
> > code string and its constant vector, among other things.  It may not be
> > as "readable", but it is infinitely more useful to the person trying to
> > debug a bug.

> 1 is "infinitely more" than zero, but it is still just 1.  Not 1`00
> and not 1000.

debug-early, using prin1, generates useful output for debugging problems
in early bootstrap.  Using cl-prin1, the output is less useful.

> IOW, just because relatively you get an "infinite" improvement, the
> net improvement is still very small, and there's no reason to stop
> there.

The improvement is significant.

For what it's worth, I think debugging in Emacs, at whatever level, is
currently too hard, too uncertain, and too laborious.  I've been working
to try and improve this for quite a long time.

> So your argument against cl-prin1, if taken to its logical conclusion,
> should be rephrased as "let's improve cl-prin1", not "let's go back to
> the infinitely useless prin1".

My main argument against cl-prin1 is that it's Lisp, and loading Lisp in
early bootstrap is an uncertain, difficult process, as this bug shows.
The guiding design principle in debug-early.el was to use _NO_ Lisp at
all, other than debug-early.el itself.  This was for the sake of the
solidity which temacs has, in comparison with the unprocessed Lisp
source files.

prin1 is _far_ from "infinitely useless".  I've used it to good effect.
cl-prin1 is not useful for printing compiled functions.

How about this suggestion: to fix the bug right now, we put prin1 back
in, as it was in the original debug-early.el.  When cl-prin1 has
improved sufficiently, we then consider putting it back into
debug-early.el?

-- 
Alan Mackenzie (Nuremberg, Germany).