|
From: | Michael |
Subject: | bug#51037: [PATCH] Make `print-level` & `print-length` customizable in ERT batch tests |
Date: | Sat, 13 Nov 2021 18:55:08 -0800 |
User-agent: | mu4e 1.4.15; emacs 28.0.50 |
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 limitis 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 wasthat if code exceeded max-lisp-eval-depth, and the debugger wastriggered, *then* backtrace.el might have problems. Do you see areason 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>
[Prev in Thread] | Current Thread | [Next in Thread] |