[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#61847: debug-early-backtrace only works some of the time.
From: |
Stefan Monnier |
Subject: |
bug#61847: debug-early-backtrace only works some of the time. |
Date: |
Tue, 28 Feb 2023 14:58:31 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
>> 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