Add ability to display high intensity ANSI colors in debug console

[indiejames]

The debug console honors ANSI color codes embedded in strings, but it treats high intensity color codes the same as low intensity, i.e., dark colors. It would be useful if the high intensity color codes generated the high intensity colors. I realize that using ANSI color codes in the debug console is an undocumented feature, but it is a very useful one. See the screenshot below for an example of how my debugger/extension uses them to do syntax highlighting of code evaluated in a REPL.

Although the syntax highlighting is better than no highlighting, it would be even better if the colors were brighter and a better match for the syntax highlighting in the editor. Please allow high intensity color codes to display as such in the debug console.

[kayahr]

Looks like the problem is not a missing high-intensity-color support. I think the problem is that each ANSI escape sequence fully overwrites the previous state. ESC[31mESC[1m must set the color to red and then switch to high intensity. The debug console instead switches to bright white. Sending the sequence in reverse order (ESC[1mESC[31m) set the color to low-intensity red because the high intensity is reset by the second sequence.

Another problem is that it is not possible to set the color and the intensity with a single sequence. ESC[31;1m isn't supported at all.

Here is a small sample program to reproduce the problem:

console.log("Default");
console.log("\x1b[31mRed\x1b[0m");
console.log("\x1b[31m\x1b[1mRed, Bold\x1b[0m");
console.log("\x1b[1m\x1b[31mBold, Red\x1b[0m");
console.log("\x1b[31;1mRed+Bold\x1b[0m");

The output must look like this:

But unfortunately it looks like this:

EDIT: Using the Inspector shows the actual problem. The escape-sequences must generate nested span tags to achieve a bold red color but vscode doesn't do that:

[isidorn]

Thanks for the great analysis. PRs welcome on fixing this
Code pointer

[saeedtabrizi]

@roblourens , isidorn is there any update ?

[isidorn]

@saeedtabrizi no, but we accept PRs to fix this

[jpike88]

If I'm a newbie, how hard would it be for me to dive in and fix this?

[isidorn]

@jpike88 Should not be easy, but also not super hard. The code pointer is still valid, so you can try making changes to ReplViewer and try to start supporting all the ansi colors. You can deffinetely try and see how it goes.

[danielfrankcom]

@jpike88 Are you going to work on this issue? If not I'd like to take it up, but you have priority if you want it.

[jpike88]

@danielfrankcom All yours man, if you have trouble I’ll dive in.

[danielfrankcom]

Hey guys, I fixed the problem in question.

The only other problem that I see is that the "bold" text isn't very distinctive compared to the weighting in other terminals such as Powershell. Is this something that we want to look at correcting too?

[isidorn]

@danielfrankcom fyi I prefer smaller seperate PRs. So fixing the bold can be part of another PR in case we decide to do it

[jpike88]

@danielfrankcom could you confirm whether this will work with https://github.com/Marak/colors.js?

[danielfrankcom]

Here is a screenshot of the current master:

And here is a screenshot of the feature branch:

So in short, no it will not. The only difference I see between these 2 screenshots is the "Chains are also cool." line which is now bold, however many of these things are currently not supported, such as underlining, custom background colors, the zebra thing, and the inverse background/foreground thing.

For reference:

[danielfrankcom]

If there is some interest, I may look at including some of these things as features, and possibly adding a pull request to make the bold ... more bold?

[jpike88]

Damn, weird. I wish this wasn’t so complicated. I’ll flag this to the colour.js maintainer as an FYI

[danielfrankcom]

I've added the underline styling, though it still won't work perfectly with colors.js because of the order in which they have used the ANSI codes.

The line console.log("Underline that text".yellow.underline); produces the following ANSI codes:
"\x1b[4m\x1b[33mUnderline that text\x1b[39m\x1b[24m"

This places the underline code before the coloring, and causes the debug line to look like this:

If the ANSI codes are placed in the correct order then the output is correct like this:

There's nothing that I can do about this specific issue, so the code in the colors.js would have to be modified to solve this.

[isidorn]

Thanks to @danielfrankcom this issue should now be fixed. I only tried with simple examples on my machine and it works nicely.
Please try it in vscode insiders from tomorrow and let us know how it works. Thanks

[jpike88]

@danielfrankcom could you do me a favour and throw your five cents in here?

Marak/colors.js#218

I'm about to start looking at tweaking colors.js but the repo owner is present there, would be great to see an exchange between you two as I look into it.