Reset is added/removed in various cases #2
Description
After d228a29, there are a number of cases where the reset code is not passed through, or added. In some cases, it doesn't matter too much, others it causes incorrect rendering.
The first case (that doesn't matter too much, but broke Cargo's CI), is two resets in a row, which for some reason rustc likes to generate. These get squashed to one reset.
| Input | \u{1b}[0m\u{1b}[0m |
| Output | \u{1b}[0m |
The next is when a string starts with a color without a reset, a reset gets added:
| Input | \u{1b}[1mbold\u{1b}[31mred\u{1b}[0m |
| Output | \u{1b}[0m\u{1b}[1mbold\u{1b}[0m\u{1b}[31mred\u{1b}[0m |
This causes rendering changes:
Another case is when reset codes are in the middle of a series of codes:
| Input | \u{1b}[42m\u{1b}[0m\u{1b}[31mred?\u{1b}[0m |
| Output | \u{1b}[0m\u{1b}[31m\u{1b}[42mred?\u{1b}[0m |
This is somewhat due to how termcolor works. ANSI is stateful, but termcolor does not track the current state, and so each color change resets everything. But fwdansi is now partially stateful, and doesn't quite match what I would expect.
It would be ideal if fwdansi was completely idempotent when emitting ANSI. It would also be ideal if it handled colors on Win 7/8 in such a way to simulate ANSI stateful behavior. These two issues might be in conflict with one another, since termcolor works fundamentally differently from ANSI.