Open epage opened 2 years ago
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.
I assume we'd either do a debug representation of the string or only do this if the string is 1 character long.
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?
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
My proposal is we'd escape
\t
, \n
, \r
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.
That list seems fine to me, it can always be tweaked later.
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: https://github.com/ordian/toml_edit/issues/259