Fix Dict limit printing of small values ending with color

[Liozou]

The recent #37568 added handling of colors in Dict printing with :limit => true in the IOContext. There is a lingering bug when the last character of the printed value is colored, which results in an additional … character being printed and color-bleeding, for example in the following picture:

This is due to IgnoreAnsiIterator skipping the last characters of the value (since they are ANSI end delimiters), then seeing that the entire line has not been printed, and thus wrongly assuming that the limit size has been reached.

With this PR:

[Liozou]

This PR does not handle the remaining color-bleeding problem if the value printed does actually reach the limit size

[KristofferC]

Did you mark this as draft because you intend to also fix the issue noted in the last comment?

[Liozou]

Yes and I think the Windows CI error might be legit because I don't see it on other builds. I'll try to look at it this weekend.

Regarding the issue in the last comment, I can think of a fix consisting in recording the encountered ANSI sequences directly in the IgnoreAnsiIterator and printing the corresponding end delimiters if they were not printed before and we hit the limit size. I need to think on how to do that efficiently, but it seems doable.

[Liozou]

The diff ends up a bit larger than I thought but to summarize:

• the text_colors const is moved from util.jl to show.jl to make it available earlier, but the definition is not changed.
• all cases of color bleeding in Dict limit printing should now be handled. Specifically:
  • if the input string contains the adequate ANSI end delimiters at the position of truncation, those are used.
  • otherwise, the appropriate end delimiters are added before the truncating characters.
• performance-wise, there should be no difference on strings without ANSI delimiters, and the additional overhead is a Dict lookup on each ANSI delimiters so it should be minimal.

Examples:

[KristofferC]

What's the reason this became so complicated? It seems that naively you just want to write the text but only count characters, when the total number of characters you want is reached, you turn all attributes off and print the three dots, similar to the first implementation that had some off by one or something.

[Liozou]

You're right, it was probably too complicated to maintain. My goal was to modify the string as little as possible, hence only adding a "\033[0m" ANSI sequence when strictly necessary, which meant not adding it when all ANSI start delimiters had their corresponding end delimiters... But let's just simplify it all. In the new commit 596ab8a I just append "\033[0m" if we encountered an ANSI delimiter in the string and the last encountered delimiter was not "\033[0m" itself.

As an aside, the previous implementation did not handle characters with width larger than 1 correctly in some corner cases (d10 in the tests would print a 16-long line where the limit is 15), so that is fixed as well. And this implementation avoids matching the regex against the entire string, which could be wasteful if it is very long.

[KristofferC]

This doesn't seem 100% correct still?

The alignment on the second row is off?

[Liozou]

Thanks for noticing! There was a rpad call down the file which messed up the alignment since it does not take ANSI delimiters into account. I integrated the rpad logic to _truncate_at_width_or_chars to fix that (and incidentally tweaked the optional arguments arguments of that function).
I reworked the PR around the new ANSIIterator which iterates over the input string but groups the sequence of ANSI delimiter characters into a new ANSIDelimiter type. That way, it's easy to handle differently a regular Char from an ANSIDelimiter and I think everything is clearer.