Michael writes:
My personal incliniation is to remove the
`backtrace-line-length`
variable entirely, and make the `debug` package responsible for
controlling print-level so as to avoid 31919. But that's me: is
there a compelling use-case for backtrace.el working in terms
of
limiting line length rather than just using
`print-le{ve,ength}`?
The motivation for `backtrace-line-length` was to find a
compromise that
made backtraces more user-friendly in interactive debugging for
both
small and large data structures. Setting `print-level` and
`print-length` too small will create a lot of ellipses in small
data
structures, making you have to expand those ellipses to see your
data;
setting those variables a little bit bigger will unleash
exponential
growth in line length for large data structures, causing delays
of
seconds to minutes when rendering and navigating your backtrace.
The
heuristics in `cl-print-to-string-with-limit` try to do a
reasonable job
with both small and large data structures, so the user can get
on with
debugging, rather than first having to figure out values of the
`print-`
variables which will make debugging possible.
Another goal of backtrace buffers is to make the data structures
represented there be completely navigable, which is why lines
are not
simply truncated.
If you don't want ellipses in your backtraces, then bind
`backtrace-line-length` to nil or zero. If you want to see how
long a
backtrace line can get, try that out with magit or org-export.