Format more text literals as multi-line strings

[sjakobi]

This causes text literals to be formatted as multi-line strings whenever they contain at least one newline and at least one non-newline character. "Spacers" like "\n\n" continue be formatted as single-line strings. If the heuristic turns out to be too eager to choose a multi-line layout, we can refine it later.

This partially addresses #1496.

[sjakobi]

Two tests currently trigger a prettyprinter bug (quchen/prettyprinter#91). We could work around that by changing pretty_ to use our usual 80-columns layout instead of Unbounded:

dhall-haskell/dhall/src/Dhall/Pretty/Internal.hs

Lines 1113 to 1117 in cc1814b

	-- | Pretty-print a value
	pretty_ :: Pretty a => a -> Text
	pretty_ = Pretty.renderStrict . Pretty.layoutPretty options . Pretty.pretty
	where
	options = Pretty.LayoutOptions { Pretty.layoutPageWidth = Pretty.Unbounded }

We also use Unbounded layouts in prettyToString, docToStrictText, and the diff tests:

dhall-haskell/dhall/tests/Dhall/Test/Diff.hs

Lines 53 to 59 in cc1814b

	let options =
	Pretty.LayoutOptions
	{ Pretty.layoutPageWidth = Pretty.Unbounded }
	let actualDiffText =
	Pretty.Text.renderStrict
	(Pretty.layoutPretty options actualDiffDocument)

[Gabriella439]

@sjakobi: As discussed in the other issue, another way you can fix this is to ensure that every use of Line/hardline has a newline-free alternative provided via a flatAlt

[sjakobi]

another way you can fix this is to ensure that every use of Line/hardline has a newline-free alternative provided via a flatAlt

It seems to me that we couldn't then enforce the multi-line formatting of the text literals that this PR is about.

If it is important that pretty_ introduces as few line breaks as possible, we could instead use something like AvailablePerLine maxBound 1.0 for the LayoutOptions.

These are the problematic tests:

1

dhall-haskell/dhall/tests/Dhall/Test/Regression.hs

Lines 90 to 93 in cc1814b

	issue126 :: TestTree
	issue126 = Test.Tasty.HUnit.testCase "Issue #126" (do
	e <- Util.code "''\nfoo\nbar\n''"
	Util.normalize' e @?= "\"foo\\nbar\\n\"" )

Here we use pretty_ via Core.pretty via normalize':

dhall-haskell/dhall/tests/Dhall/Test/Util.hs

Lines 63 to 64 in cc1814b

	normalize' :: Expr Src Void -> Text
	normalize' = Dhall.Core.pretty . Dhall.Core.normalize

2

dhall-haskell/dhall/tests/Dhall/Test/Tutorial.hs

Lines 49 to 57 in cc1814b

	_Interpolation_1 :: TestTree
	_Interpolation_1 = Test.Tasty.HUnit.testCase "Example #1" (do
	e <- Util.code
	"''\n\
	\ for file in *; do \n\
	\ echo \"Found ''${file}\"\n\
	\ done \n\
	\'' \n"
	Util.assertNormalized e )

We again use normalize' via assertNormalized.

---

I think my preference would be to simply use the 80-column layout consistently, so we don't have to worry about different layout variants.

[Gabriella439]

@sjakobi: I agree that the best solution here is to consistently avoid the Unbounded layout option, because it appears that it is incompatible with output that has obligate newlines