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

[Stefan Monnier]

>> The output for compiled functions is the main one which I think is more
>> readable (among those that occur often in backtraces), so let's just
>> agree to disagree on this one.
>
> No.  The point is too important not to resolve.
>
> I think you're objectively wrong here.  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.
>
> The lack of output for compiled functions with cl-prin1 condemns it.  All
> that appears is "#f(compiled-function)" together with an empty pair of
> parentheses and a meaningless hex address.  What use is any of that in
> debugging a batch mode bug?
>
> 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.

I'm not sure what you're expecting from me.  Obviously, I'm aware of
what you describe.  I just don't reach the same conclusion.

>> > And how will the contition-case you suggest help?  (require 'cl-print nil
>> > t) returns non-nil in the pertinent circumstances.
>> The `noerror` argument of `require` doesn't silence the errors that
>> happen while loading the file, instead it prevents signaling an error
>> when the file is not found.
> Whether that error is silenced or not is wholly unimportant.  The only
> important thing here is to get a backtrace,

The silencing of the error should help to get a backtrace since it
should let the code fall back to using `prin1`.


        Stefan