Unstripped Ansi Color Codes in Metals Output

[adpi2]

Describe the bug

The Scala 3 compiler produces colored error messages that are not correctly displayed in VS Code Metals output:

2021.03.16 21:18:35 ERROR �[31m-- [E007] Type Mismatch Error: /home/piquerez/adpi2/pandora/src/main/scala/pandora/Product.scala:43:31 �[0m
�[31m43 |�[0m    (Term(tags.size, factors), mapping)
   |                               �[31m^^^^^^^�[0m
   |   Found:    �[1m�[31m(�[0m�[1m�[31mmapping�[0m�[1m�[31m �[0m�[1m�[31m:�[0m�[1m�[31m �[0mList[List[List[(�[1m�[31mAny�[0m, �[1m�[31mAny�[0m, Int, �[1m�[31mNothing�[0m, �[1m�[31mAny�[0m)]]]�[1m�[31m)�[0m
   |   Required: List[List[List[(�[1m�[32mInt�[0m, �[1m�[32mInt�[0m, Int, �[1m�[32mInt�[0m, �[1m�[32mInt�[0m)]]]

To Reproduce

Steps to reproduce the behavior:

1. Open a sbt project using Scala 3
2. Run the Metals: attempt to generate BSP config for build tool command to connect to sbt server
3. Type some error
4. See error in the View > Output > Metals panel

Expected behavior

The color codes should be stripped or displayed.

Screenshots

Installation:

• Operating system: Linux
• Editor: Visual Studio Code
• Metals version: v0.10.0

Additional context

The color codes of the Debug Console are correctly displayed so they should not be stripped.
Related PR: #2615

[ckipp01]

So I'm not 100% sure this is something Metals is actually doing wrong. For example this is just displaying what we are piping to our own log file, and if you tail that file in your terminal (most terminals that is), you'll see it colored correctly. I don't believe it should be any different than the way that DAP output is colored in the DEBUG CONSOLE. I'd expect the OUTPUT panel to pick this up, although I'm not familiar with VS Code. It may be worth just digging into that a bit to see if that is indeed an issue on the VS Code side, unless we do anything to it in the VS Code extension.

[tgodzik]

Thanks for reporting! @ckipp01 might be right here. We could strip the color in VS Code output itself (which would mean it's a VS Code specific issues). Tailing it in the terminal shows the colors properly.

Digging into it a bit further it seems that the issue in VS Code was clsoed without a resolution: microsoft/vscode#571

What we can do is either strip colors when writing to output in VS Code (or via a setting in Metals) or you can actually use https://github.com/IBM-Cloud/vscode-log-output-colorizer which is an extension to VS Code and seems to work fine:

I think the second option with the additional workaround gives us much more possibilities.

Alternatively, since the extension is quite short we can include it along with the license in metals-vscode.

[tgodzik]

Actually, that doesn't strip out the ANSI escape codes. We might need to use LineListener for the build output anyway. We already seem to do it for the regular output.

[tgodzik]

It seems that it's actually being done in LanguageClientLogger - we might need to strip the ansi escape codes there using LineListener

[frou]

So I'm not 100% sure this is something Metals is actually doing wrong. For example this is just displaying what we are piping to our own log file, and if you tail that file in your terminal (most terminals that is), you'll see it colored correctly.

For general Unix hygiene, it's definitely wrong to write ANSI colour escape codes into a log file. They should not be written to anything unless isatty returns true.