Errors include unprintable or awkwardly printed characters.

[epage]

cargo has a test that tries null characters: https://github.com/rust-lang/cargo/pull/10086/files#diff-4980c43ff583070e4cb20d00368e0c15d57a0c0127d7ddc5676e1ee12b899d18R927

it also exposes that a newline is shown for errors: toml-rs/toml#259

[epage]

It'd be nice if combine did a look up an showed a word or an escape sequence instead of rendering these characters.

I'd be willing to implement this, just want the go ahead first.

[epage]

I assume we'd either do a debug representation of the string or only do this if the string is 1 character long.

[Marwes]

Just using https://doc.rust-lang.org/std/primitive.str.html#method.escape_default and the same method of char might be good when rendering?

[epage]

I think the main question is handling of unicode, whether those should be escaped or not. I think most users can see and understand a unicode character but the escaped form is a
bit more mystifying (at least for this ASCII-only person)

It can be a good start though

[epage]

My proposal is we'd escape

• unprintable
• \t, \n, \r
• Our quote character (back-quote)

I'd personally not escape \ since we are creating something for humans and I think humans would be able to understand the message.

The challenge with any of this is the impl Display for Info is for Info<T: Display, R: Display>. For non byte / char, we could end up munging people's tokens (granted, 99% of custom tokens will probably be unescaped). Though this is making me wonder how we are doing pretty printing of byte tokens which toml_edit is using.

[Marwes]

That list seems fine to me, it can always be tweaked later.