bug#51037: [PATCH] Make `print-level` & `print-length` customizable in ERT batch tests

[Michael]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Michael <sp1ff@runbox.com> writes:
>
> > I was thinking to augment the docstring for
> > `backtrace-line-lenght' to note that print-level & print-length
> > will be overiden to honor it.
>
> Sounds good.
>
> > The problem is that I can't know a priori how big I have to set
> > them in order to honor print-level & print-length.
>
> No, but I thought the issue was with the corner case where we're 
> almost
> up against the limit already?  To work around that, doubling the 
> limit
> is fine in this context.
>
> > I think I can short-circuit this entirely by setting
> > `backtrace-line-length' to nil or zero before printing the 
> > backtrace
> > from ert. eval-level shouldn't enter into it I think; the 
> > concern was
> > that if code exceeded max-lisp-eval-depth, and the debugger was
> > triggered, *then* backtrace.el might have problems. Do you see 
> > a
> > reason to be concerned outside of that corner case?
>
> If that works without upping the limit, then that's fine.

OK-- here's the revised patch.

Gemini was on to something-- even modest settings for print-level
& print-length can produce *extremely* long lines in backtraces,
with corresponding execution pauses. So I:

 - fixed the minor error in backtrace.el so that setting
   backtrace-length to nil has the desired effect (i.e. removing
   any line length limitation)
 - introduced a third variable ert-batch-backtrace-line-length,
   with the following permissible values:
   - nil: remove any limitation on backtrace line length (full
   backtraces)
   - t: just use the value of backtrace-line-length
   - positive int: use this value to limit line lengths in
   backtraces

0001-Make-print-length-print-level-in-ert-run-tests-batch.patch
Description: Updated patch for ert-batch-print-length & -level

--
Michael <sp1ff@runbox.com>