Debug console uses unexpected text colours for some strings

[DanTup]

Add the following code in an extension:

console.log('true vs true');
console.log('true vs false');
console.log('false vs true');
console.log('false vs false');

When it runs, the colours of the output lines are inconsistent:

Looking in the dev tools, it seems the blue lines have boolean in their CSS class which is missing from the white lines. It seems strange that true vs false and false vs true are categorised differently.

[weinand]

@isidorn why do we try to colorise stuff in the debug console?
I remember that I've already filed an issue about numbers being colorised in strange ways.

[isidorn]

@weinand currently we use some simple regex heuristics to try to colorise booleans, numbers and strings.
Also we colorise some ANSI output.

I can remove all of these colors but not sure if it will upset the users.
And yes I agree that the colorisation is a bit flaky.
Suggestions on what to do here are very welcome.

[weinand]

@isidorn please remove the regex heuristics for colorising because it is surprising and mostly wrong. But keep the ANSI coloring because it is deterministic and expected.

[isidorn]

@weinand makes sense. Do you get a sense that it is mostly wrong also in the watch and variables pane since we use the same heuristic there. Should it also be removed there?
IMHO it is giving some additional info in those panes and nobody complained so we should keep the heuristic for the variables and watch

[DanTup]

My 2¢...

I was surprised to see colours in the debug output. I'm not against it, though if it's kept it should be reliable.

If the same regex is being used for the watch window, then even if colours are removed from the debug console, then I think the regex needs fixing, since it'll presumably also color the string "false vs false" and "false vs true" differently?

[weinand]

If we want to continue to support regexp-based "value colorisation", we should only do it where we control and understand the underlying syntax. This is true for the variables and watches view and for structured objects in the debug console since all are trees.
But we should not try to do it where we have no clue what the underlying structure is. This applies to to all "string" output in the debug console. Here only the ANSI colours should be honoured.

For the trees we should make sure that the regexps only match simple values like true and falsebut not something like true and false or a trueembedded in a string.

[isidorn]

Thanks.
Now we do not colorize in repl outside of a tree.

@DanTup I have checked the boolean regex and it looks fine to me. I think the difference in coloring comes from the fact that those output elements came in a different order from the adapter. Which means that part of tha string first came which passed the regex check making it blue.
Though this will no longer happen since I removed color for that case in the repl

[DanTup]

@isidorn I don't understand the explanation for it happening (the output is in the same order as the console.logs?) but I don't know the internals of how the data gets back to the debug output window. If it makes sense to you (and is no longer an issue anyway), all sounds good to me 👍

[isidorn]

@DanTup no it does not make 100% sense to me either, I was just speculating as to what might have been the cause. Since the adapter can send the output events chunked to vscode (I did not investigate further)

[roblourens]

It would be nice to keep colorization for 'evaluate' requests, since the result has a 'type'. node2 doesn't set the type... it could though.

vs previously

[isidorn]

@roblourens please file a feature request to me to respect the type in the debug console for colorisation