`assertNoDiff` should or not ignore the character 127 - DELETE (U+007F)

[FabioPinheiro]

Its not clean if the character 127 - DELETE (U+007F) should or not ignore by the method assertNoDiff when comparing to strings.

Character 127 - DELETE (U+007F) is a general ASCII Codes that was no representation (not visible).

I see in

munit/docs/assertions.md

Lines 165 to 170 in 2cd88c6

	The difference between `assertNoDiff()` and `assertEquals()` is that
	`assertEquals()` fails according to the `==` method while `assertNoDiff()`
	ignores non-visible differences such as trailing/leading whitespace,
	Windows/Unix newlines and ANSI color codes. The "=> Obtained" section of
	`assertNoDiff()` error messages also include copy-paste friendly syntax using
	`.stripMargin`.

The difference between `assertNoDiff()` and `assertEquals()` is that
`assertEquals()` fails according to the `==` method while `assertNoDiff()`
ignores non-visible differences such as trailing/leading whitespace,
Windows/Unix newlines and ANSI color codes. The "=> Obtained" section of
`assertNoDiff()` error messages also include copy-paste friendly syntax using
`.stripMargin`.

But there are also many parts of the base they referred only as ANSI escape characters instate of ANSI color codes. Even the fail message from the method assertEquals hits for that (values are not equal, even if their text representation only differs in leading/trailing whitespace and ANSI escape characters)

So which characters should be ignored?

[tgodzik]

This seems a tricky topic, but ideally all incompatibilities between the compared strings should be mention. There is plenty of non visible characters though and we might not account for everything.

[FabioPinheiro]

So what do you suggest?

• just close the ticket
• add a test registering the current behavior

[tgodzik]

It would probably be worth documenting the current behaviour though I don't think I will have the time to look at it.