White backgrounds are super bright, which always hurts my eyes. This is why the orange in my background used to be darker, but that admittedly had problems. So I worked quite a bit to lighten it without putting it in so-bright-it-hurts like white or straight pumpkin orange.

Some people elsewhere have suggested a different foreground colour might work, but I haven't found anything other than black and near-black that even show up well on orange.

Trying to make a dark background with black text is never going to work. Either make the background dark and the text white, which people will complain about, but a lot less, or do it the normal way with a light background and black text.

Indeed. After black and white, red is the most contrastive color. Thus, it is best avoided in backgrounds. Use black. Use white. Use grey. Use green. Use blue. Use purple. Just stop already with the red/orange. The only way you're going to get that to be anywhere near legible is if you head straight to the light salmon or the carnation pink.

If you absolutely must have a hot tone: this is a light color. This is a light color. What you have up there now is not "quite light".

What I have up there now is peach, but ok. It seems I've reached a point where I'm not happy with my colour and people don't like it any better. Also, I finally understand that it's not a contrast/legibility issue, but a matter of taste, which makes more sense.

If I get some time I may look at doing a complete redesign. It's been awhile :)

Ah you're right about blaze-builder's fromText. Weird. But why not use the Text builder instead? I'm not sure why people use bytestrings for things that are naturally text. I guess it is faster if you're rendering to exactly the one encoding you decided to default to?

You seem to be doing a lot of Builder.fromString and T.pack. If you use OverloadedStrings you might benefit from the rewrite rules in the text package, which convert from string literals to Text at compile-time instead of runtime. Also, generating code like this all over the place:

Builder.fromLazyText $ displayT $ renderPretty 0.4 80 $ pretty

is probably suggestive of that you shouldn't be using a pprint library at all. If all you need is basically "Show without quotes for strings and text" it might be better to just write that type class yourself after all. Might also allow you to avoid some orphan instances; duno if you're running into those yet.

Show without quotes for String and Text, and with empty for Nothing and just the x for Just x, basically "formatting for display". I was pointed at these libraries as a way of doing that, and the default instances matched my expectations.

Interesting that the conversion from string literal to Text can happen at compile time with OverloadedStrings. I had always assumed that since it uses IsString it was still doing the conversion at runtime. Or else I would think it could also do it at compile time witthout OverloadedStrings, but maybe the extension has some extra magic beyond just inserting fromString everywhere?

While pretty printing libraries do what you want, they also do a whole lot more, and the intended usage is that you print everything as one Doc and render that once, not that you render small things individually here and there. I use it to render JS and CSS syntax trees into actual JS and CSS with pretty indentation and alignment and such. You could do this instead of using a Builder for your Mustache thing, but it wouldn't really give you anything since Mustache is text templating without structure.

The text package uses GHC rewrite rules; see relevant commit. This will probably not be a win if you use blaze-builder though, so mostly relevant if you switch it to a text builder.