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

[Alan Mackenzie]

Hello, Eli.

On Tue, Feb 28, 2023 at 16:22:30 +0200, Eli Zaretskii wrote:
> > Date: Tue, 28 Feb 2023 13:16:42 +0000
> > Cc: monnier@iro.umontreal.ca, 61847@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > It isn't clear to me why you consider code that uses prin1 to be "rock
> > > solid by design".  Please elaborate.

> > I meant that the specific piece of code which was the original code
> > (which happened to use prin1) was rock solid, not any other use of prin1.

> > The original code didn't depend on any other lisp being loaded.  Given
> > how much can go wrong with loading Lisp in the early bootstrap in a
> > version of Emacs being debugged, and which did go wrong in the bug
> > scenario, I say we're better off not trying to use cl-prin1 at this
> > stage.

> If you think that the original code is solid because no Lisp is
> loaded, then all it takes to break that is that someone rewrites prin1
> in Lisp.

That seems unlikely, since the C code needs some way of outputting
information before the Lisp even exists.

> Which happened with quite a few primitives in recent years, and so it
> can happen with prin1 as well.  And if that does happen with prin1,
> who will remember that this particular piece of code cannot stand
> loading Lisp and will subtly break if that happens?

I will remember it.  It would break, not at all subtly.  But you seem to
be arguing that because something can't be 100% perfect, it shouldn't be
improved.

> So if this feature needs some precautions when loading Lisp, we had
> better introduced those precautions now, and tested them with Stefan's
> code which uses cl-prin1 to make sure it works.

Why?  The code doesn't need cl-prin1, that's just a source of errors,
such as the one that happened.  I've asked Stefan why cl-prin1's output
is somehow more readable than straight prin1.

> That way we will have a more future-proof feature.

Not at all.  The original debug-early was as future-proof as it's
possible to get, and that was by deliberate design.  The current buggy
version, because of all the complexities of loading Lisp, is much less
dependable.  Even if some workaround is found, it will still be less
dependable.

Why do we want to use cl-prin1 here at all?  It doesn't appear to have
any advantages to offset its lack of dependability in early bootstrap.

-- 
Alan Mackenzie (Nuremberg, Germany).