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

Previous Next

Full log

Message #61 received at 51037 <at> debbugs.gnu.org (full text, mbox):

From: Michael <sp1ff <at> runbox.com>
To: Gemini Lasswell <gazally <at> runbox.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>,
 51037 <at> debbugs.gnu.org
Subject: Re: bug#51037: [PATCH] Make `print-level` & `print-length`
 customizable in ERT batch tests
Date: Tue, 26 Oct 2021 14:02:31 -0700

Gemini Lasswell <gazally <at> runbox.com> writes:

> 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.

lol... I see. So you found `backtrace-line-length` to be more
ergonomic than print-level & print-length at controlling
verbosity (at least where backtraces are concerned)-- fair?

One thing: when I evaluate this:

   (let ((print-length nil)
         (print-level nil)
         (backtrace-line-length nil))
     (backtrace-to-string))

I receive the following error message:

   backtrace-print-frame: Wrong type argument: 
   number-or-marker-p, nil

I take it that is unexpected? It's fine if so, I'm happy to
debug, I just want to be sure I'm not running off down the garden
path.

-- 
Michael <sp1ff <at> runbox.com>

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.