`cmark`’s pretty-printer matches our output pretty well, with a few differences:
- it puts a space between the fence and the info string for in code blocks;
- it prefers `-` over `*` for bulleted lists (as do I) and it indents them;
- it `\`-escapes certain chars very conservatively;
- it prefers indented/unfenced code blocks if there is no info string; and
- it prefers `*` over `_` (unlike any sane person).
This also shows how the change fixes a number of issues:
- fix2158-1.output.md also illustrates how this change fixes#1809;
- alias-many.output.md and input-parse-errors.output.md show how fenced
code blocks without an info string would use the beginning of the
content as the info string;
- transcripts-round-trip/main.output.md shows how output blocks for
generated `unison` stanzas (which could contain nested fenced blocks)
might not have long-enough fences; and
- error-messages.output.md and generic-parse-errors.output.md show how
Unison errors were reported on the wrong line number (and thus the
printed error lines were also incorrect).
- `Value.validateSandboxed` checks an interchange value for sandboxing
before it is decoded. It either returns a list of dependencies the
runtime doesn't know about yet, or a list of disallowed builtins, both
as lists of termlinks
- `sandboxLinks` returns the list of sandboxed builtins transitively
referenced by the code associated to a given termlink
Adding a Pattern.captureAs which will act just like capture, but
additionally takes an `a` which will be used as a replacement for the
capture.
My motivation for adding it is that I want to match on escape
sequence, but actually capture the unescaped character instead.
For example:
```
Pattern.captureAs "\n" (Pattern.literal "\\n")
```
- Just zipping the lists will report that any two lists with the same
prefix are equal. So, instead, compare the lengths if the zip check
reports equality.
- Added a few tests for list equality to builtins.md
The sandboxed dependencies for combinators were being computed just from
the previously known combinators. So, if multiple new, interrelated
combinators were introduced simultaneously, their full transitive
dependencies wouldn't take into account anything in the new set.
To fix this, just iterate the dependency inference until a fixed point
is reached.
