This is necessary to ensure that strings I don't have examples of work
properly. The same thing applies for double-encode and double-decode
usecases.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
This results in all multi-byte characters to be encoded in a way that
naive unvis(3) implementations will not bork up the encoding. In
addition, it also ensures that the output of Vis will always be ASCII
*only*.
Also test far more cases in *_test.go when it comes to different flags,
and do far more tests to ensure that the output of Vis() makes sense.
These outputs come directly from vis(3) and so are useful regression
tests to ensure that the handling of Vis() is identical to the original.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
While these characters are really weird to handle, here is a fairly
simple implementation that need some more testing (and a proper
secondary source to compare against).
Signed-off-by: Aleksa Sarai <asarai@suse.de>
In particular, previously such escape handling would break because we
would attempt to encode characters >0x7f as runes -- which would then
result in escapes that want to encode multi-byte characters breaking.
There's still some work necessary in Vis() to make it act sanely when it
comes to arbitrary bit streams. Not to mention that we need to figure
out what we actually want to do there...
Signed-off-by: Aleksa Sarai <asarai@suse.de>
This is a stopgap while I figure out how I should go about implementing
vis(3). It's also important to have some vis(3) implementation so I can
do integration tests on round-trips.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
Also add some unit tests -- one of which currently fails due to ongoing
design discussion about how certain escape codes should be handled.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
