`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).
- The check was looking for occurrences of `f x y z ...` to make sure it
was safe to eliminate variables that had been added by enclosure.
However, it wasn't finding occurrences of `f` by itself, because that
is not considered an application by the predicate that was being used.
- I also made the 'fix-up' code default to not eliminating any variables
when there are *no* subsequent occurrences of `f`. Previously this
would allow eliminating as many variables as possible. However, this
can produce ill-scoped definitions. Avoiding this would require
knowing which variables are in scope when reducing an unused
definition, but that would require a more complicated rewriting
process than is currently used.
- visit_ was producing problematic results, because it visits every
subexpression. This means that for:
f x y z
it visits all of:
f x y z, f x y, f x, f
But, if we take prefixes for all of those, we'll always end up
eliminating only one variable, even if more are redundant.
- Instead of the above, use `visit` with a recursive procedure. This
requires some other modifications, because we need to manually recurse
into arguments of applied functions that aren't variables.
- Added a test case for the above trickiness
- Prefix should have been a newtype
