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

[Alan Mackenzie]

Hello, Eli.

On Wed, Mar 01, 2023 at 18:01:24 +0200, Eli Zaretskii wrote:
> > Date: Wed, 1 Mar 2023 15:22:29 +0000
> > Cc: monnier@iro.umontreal.ca, 61847@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > And what use is the meaningless stream of raw bytes that prin1
> > > produces?

> > If that were indeed what was produced, none at all.  Because
> > debug-early-backtrace binds print-escape-control-characters to t, what
> > actually gets produced is a mixture of ascii characters and octal
> > escaped representations, just like you see when an .elc file is visited
> > in Emacs.

> Escaping raw bytes doesn't make them more comprehensible.

It does, if they contain control characters which would otherwise corrupt
the screen.

> > > I think you should re-evaluate your preferences, and base them on real
> > > advantages and disadvantages, not on imaginary ones.

> > What makes you think I'm not doing this already?  I wrote debug-early
> > last year because I _needed_ it.  I've a lot of experience using it, and
> > the way it prints (or rather used to print) a compiled function is/was
> > useful.

> For you, maybe.  Not for me.  For me it's a nuisance.  A useless waste
> of screen estate.

Yes, for me, and lots of other people too.  Byte code is very compact,
and we're talking about a very few lines of screen "wasted".

> > You can see how many arguments it takes.

> That information exists elsewhere.

You're misunderstanding the situation.  You see a lambda form represented
in a backtrace, you don't know which lambda form it is.  There are over
8,000 of them in Emacs.  Knowing the number of arguments helps identify
_which_ lambda form it is.

> > You can see the byte code string, hence enabling you to compare it
> > visually with the contents of a .elc file, should such already
> > exist.

> Let's be serious, okay?

I'm being perfectly serious.  I've done this.  It enabled me to be sure
that I'd identified the lambda form in question, removing the doubt.

> > > If we want our backtraces to be more informative, not less, we
> > > should move farther away of "dumb" output functions that just spill
> > > the guts and towards more humanly-readable formatted description of
> > > the called functions.

> > A wholesome long term goal I fully agree with.  For the here and now,
> > outputting "#f(compiled-function () <random hex address>" and nothing
> > else is not a step in that direction.

> But using cl-prin1 _is_ a step in the right direction, because it
> allows us to extend the feature.

Well then, let's get cl-prin1 up to the state where it is better than
bare prin1.  As I keep saying cl-prin1 is useless for printing compiled
lambda forms at the moment.

> And that is why I said that if loading Lisp breaks something in
> debug-early, we should solve this _now_, not fall back on prin1, which
> by its very nature cannot be extended so easily.

That it cannot be extended easily is not a disadvantage.  It means there
is always a dependable debug-early-backtrace.  The attempt to load
cl-prin1 into debug-early is precisely what caused this bug.

> > Besides, the idea of debug-early is to generate a backtrace before all
> > the fancy Lisp facilities are available.

> Some fancy Lisp facilities are already available anyway.  And I see no
> reason for this requirement in this case.

In a situation where Emacs does not bootstrap, instead crashing during
the loading or compiling of the Lisp files, we need a debugging tool
which isn't dependent upon those Lisp files.  That is what debug-early.el
is intended to be.

-- 
Alan Mackenzie (Nuremberg, Germany).