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