bug#36566: 27.0.50; debug is sometimes horribly slow

[Lars Ingebrigtsen <larsi@gnus.org>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> But maybe for this specific issue we could make it so
> `print-char-length` is only obeyed by `cl-print` (and only when
> `cl-print-readably` is nil) and not `prin1` (which is the function that
> prints in a machine-readable way and should hence arguably never
> truncate).

Ah, yes, that's true...  it's not really that big a deal with the new
variable if we do it that way.

>> I did suggest (in conjunction with another bug report in this area) that
>> we should just extend `prin1{,-to-string}' with a parameter that would
>> set (on the C level) an equivalent variable.  So we'd have
>> (prin1 object fun `((char-length . ,edebug-print-char-length)))
>> etc.  (And `t' would be "all defaults".)
>
> Some kind of "print context" object would be good, indeed.
> Being able to set/modify this context "at a distance" via dynamic
> scoping is quite handy, tho, so we probably want to still support that
> as well.
>
> Here's an idea: a print context could include an `inherit` setting which
> says whether to "keep looking for more settings from the context".
> Then we printing we use settings from:
> - the explicit context passed as arg (if present).
> - the currently existing `print-<foo>` vars (if there isn't an explicit
>   context arg whose `inherit` says not to do that).
> We could even go crazy and add an intermediate step to check
> a `print-context` var which contains such an object.

I was thinking something along the lines of

(prin1 object nil '((depth . 4) (circle . t)))

to "bind" only those two, and t as a special value for "all the
defaults" (i.e., print-length/depth/etc to nil), but you can also mix
and match:

(prin1 object nil '(t (depth . 4) (circle . t)))

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no