We already have --color/--no-color CLI options, they just do not affect Standard JSON. Same for --pretty-json (which was quite unexpected to me at first). Setting the default for Standard JSON to --no-color and making these options affect both JSON and non-JSON mode should not break any tools so I think it would be the best choice.

By the way, if we start colorizing standard JSON then I think that --color/--no-color should affect --combined-json too for consistency.

I'm not sure it is a good idea combining CLI options and standard json settings. --pretty-json is fine, but if you use --color to influence standard json output, then what do you do with the setting within standard json?

color would be good

@axic Do we actually need a setting inside Standard JSON? Description does not state that outright but I thought it was about colorizing JSON when it's displayed in the terminal. I.e. with --standard-json but not necessarily solc-js. I think that a command-line flag makes sense in that usage.

But if it's supposed to work with solc-js too - do ANSI escape sequences embedded in strings inside JSON even make sense outside of the terminal? I see there are some JS libs for parsing them but if it's meant for JS tools, I think they would highly prefer some semantic markers that can be used to style them in a custom way rather than hard-coded colors.

Can someone check how coloured strings would be displayed by e.g. remix or vs code?

Do we actually need a setting inside Standard JSON? Description does not state that outright but I thought it was about colorizing JSON when it's displayed in the terminal. I.e. with --standard-json but not necessarily solc-js. I think that a command-line flag makes sense in that usage.

This is definitely not about colourising the JSON, but rather including colours in the formattedMessage. (That being said, anyone using | jq could also benefit.)

Can someone check how coloured strings would be displayed by e.g. remix or vs code?

There are libraries which can turn ANSI escapes into HTML markup. I think Remix had something like that for some purposes, but I'm not 100% sure, @yann300?

That is why this should be off by default, but tools can request it and process it.

I think they would highly prefer some semantic markers that can be used to style them in a custom way rather than hard-coded colors.

They already have that by now using formattedMessage, they can build up the contents themselves. The colour output in formattedMessage is for those who do not want to deal with formatting.

Looks like Hardhat wants to add error coloring so this could be useful to them: nomiclabs/hardhat#680. I asked if ANSI escapes would work for them.

BTW, I have created a separate issue for --pretty-json: #11583. It's an easy one so it perfectly fits the good first issue label.

They already have that by now using formattedMessage, they can build up the contents themselves. The colour output in formattedMessage is for those who do not want to deal with formatting.

I just checked to see how it's formatted and expected to see some markup in there but looks like it just includes the error type and a code snippet with a marker pointing out the error:

"formattedMessage": "ParserError: Source \"util.sol\" not found: File outside of allowed directories.\n --> contract.sol:1:1:\n  |\n1 | import \"./util.sol\";\n  | ^^^^^^^^^^^^^^^^^^^^\n\n",
"message": "Source \"util.sol\" not found: File outside of allowed directories.",

I don't think it's that's easy to style unless you start actually parsing the messages.

Can we talk about this in the next meeting? I as i was doing the prior work, i have some questions (/concerns).

1. Enable colours by default and do not allow it to be turned off

Do you mean also for the existing case when printing to the CLI? I think that should still be guarded by isatty(STDOUT_FILENO) unless explicitly enable/disabled.

4. Store the coloured message in a new field (such as coloredFormattedMessage

If the IDEs are printing these messages as-is to the user, I think that does make sense - at first though I was a little scared/confused, because I may have thought that the IDE would not do that, because we provide source location offsets and the IDE could just highlight in the source code.

I think enabling that by default might not be good due to existing software not expecting this (?).
Stripping off VT (CSI) sequences however should be very easy (this FSM might scare on first sight, but we are only interested in the CSI case, that can be matched via basic regex).

Instead of providing the error message twice, I'd suggest to add a boolean "colored" flag that by default would be false (to stay backwards compatible).

WRT jq I think the desired option would be --raw-output.

I had a short call with @cameel, also to clarify my concerns and whether I am understanding the mission right here. I wanted to summarize now at least some thoughts we came up with in the call:

• underlines don't even have to be mimmicked via ^^^^ lines as VT does have native support for (even: curly underlines that can get a different color as the text they're being printed under, say yellow for warning and red for error. besides curly there is also support for single/double/dotted underline (exotic left out).
• we should document preciely what VT sequences we do produce: LF for newline, SGR reset (CSI m), 16-indexed color setting for foreground and (apprently?) also background as well as RGB color setting (at least CSI 48 ; r ; g ; b m). It would be simple to also add underline-mode and underline-color to it, because (surprise :-D) it's the exact same VT sequence, just with different numbers between CSI and m). CSI is the shorthand for "\033[".
• it should be mentioned that we currently indent via spaces, and that would require a monospaced font when displaying the messages (that one could probably be mitigated by using native underline sequences instead of manually writing ^^^'s under a source fragment.
• it at least came up as an idea: one could even syntax-highlight the printed AST fragment :)
• the original error message can remain the same but the additional source reference would require an additional JSON field in the reply (that may or may not be colored, based on what the client requested).

There was also a question of whether colored formattedMessage would be useful to tools. @christianparpart pointed out that it's only the actual console tools (like Hardhat or Truffle) that would potentially use it. GUI tools (like Remix or vscode-solidity) likely want only the error description to show it in a tooltip and don't need the underlining or the affected source code line. Since we do not really color anything inside the message itself, colored output would not benefit them much anyway.

They already have that by now using formattedMessage, they can build up the contents themselves. The colour output in formattedMessage is for those who do not want to deal with formatting.

I just checked to see how it's formatted and expected to see some markup in there but looks like it just includes the error type and a code snippet with a marker pointing out the error:

"formattedMessage": "ParserError: Source "util.sol" not found: File outside of allowed directories.\n --> contract.sol:1:1:\n |\n1 | import "./util.sol";\n | ^^^^^^^^^^^^^^^^^^^^\n\n",
"message": "Source "util.sol" not found: File outside of allowed directories.",

@cameel It was a typo in my message, I meant that with message and all the other fields they can replicate what we provide under formattedMessage. formattedMessage is that same what we print on the CLI.

Enable colours by default and do not allow it to be turned off
Do you mean also for the existing case when printing to the CLI?

@christianparpart this issue is solely about standard json, let's please leave the CLI out of the discussion 😅

There was also a question of whether colored formattedMessage would be useful to tools. @christianparpart pointed out that it's only the actual console tools (like Hardhat or Truffle) that would potentially use it. GUI tools (like Remix or vscode-solidity) likely want only the error description to show it in a tooltip and don't need the underlining or the affected source code line. Since we do not really color anything inside the message itself, colored output would not benefit them much anyway.

GUI tools can use all the other fields we have in the message. If they want nice formatting and tooltips, they should just build it themselves and ignore formattedMessage. If somehow we do not export a given field, then we should fix that, as that was the initial goal of this structure.