[m-rev.] for review: add color to the diagnostic generated by typecheck_errors.m

[Julien Fischer]

On Sun, 28 Apr 2024, Zoltan Somogyi wrote:

> Add color to the output of typecheck_errors.m.

...

> compiler/write_error_spec.m:
>     Fix several issues revealed by the effect of the above changes
>     on the outputs we generate for invalid test cases.
>
>     Issue one. We had a sanity check that, after joining two lines,
>     checked whether the sum of the recorded line lengths matched
>     the number of code points in the joined string. Delete this check,
>     because it does the wrong thing in the presence of color changes.
>     The reason is that the recorded lengths consider the escape sequences
>     implementing them to be zero length (since they occupy zero columns),
>     but string.count_code_points counts them anyway.
>
>     Issue two. We used to handle colors in each paragraph separately,
>     effectively starting each paragraph with an empty color stack.
>     This caused problems with messages in which a color change is supposed
>     to affect several lines *that have explicit newlines between them*,
>     since the code puts paragraph breaks after each explicit newline.
>     Fix this by setting the initial color stack of each nonfirst
>     paragraph to the final color stack of the previous paragraph.
>
>     Issue three. It is possible for an unbreakable string (such as the name
>     of a predicate) that is too long to fit in the space available on a line.
>     We have to include such strings in a line despite the violation of the
>     length limit. Previously, we had to do only when the string was the first
>     thing on the line. Now, it is possible for such a string to be preceded
>     by one or more color changes, which occupy zero columns. Include
>     too-long-to-fit unbreakable strings on the line in such cases as well.
>
>     Issue four. Some callers of the color_pieces functions pass them
>     piece lists that end in newlines. In such cases, we don't want
>     the color reset to take place at the start of the next line after the
>     colored pieces, because that makes the output harder to check visually
>     for correctness in .err_exp files. In such cases, swap the order
>     of the color_end and newline pieces. (Since newlines cannot be colored,
>     this has no semantic effect.)
>
>     Issue five. If a line either started out colored or contained pieces
>     that started colors, we marked it to be followed by a color reset

s/colors/colored/

>     when it is printed. However, if the color was already reset by pieces
>     that are also contained in the line, so that the color stack was empty
>     at the end of the line, then this final additional reset was redundant.
>     Arrange not to print such redundant resets, also in the interest of
>     making .err_exp files easier to check.
>
>     Improve the debugging infrastructure a bit.
>
>     Don't duplicate blank lines zero times.

...

> tools/bootcheck:
>     Prevent the NO_COLOR environment variable from overriding those enables.

This diff does not contain any changes to the bootcheck script.

That looks fine otherwise.

Julien.