-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New "full compiler diagnostic" view could use some color #13648
Comments
Pretty hard given the rendered output in the json output doesn't contain the color, and reconstructing that ourselves isn't really an option. |
Reconstructing the error isn't that hard, using libraries like |
Rustc supports outputting ansi color codes in the json messages and in fact that is what cargo itself uses. Not sure if cargo supports passing this through, but if it does you could parse the ansi escape codes to get the colors. |
Ye i think cargo might be eating the colors here then from what I've seen. |
As a not-optimal workaround, I found a way to get back the colors that Cargo displays by default (in VSCode at least): "rust-analyzer.checkOnSave.overrideCommand": [
"cargo",
"check",
"--message-format=json-diagnostic-rendered-ansi"
], Then use an extension like https://marketplace.visualstudio.com/items?itemName=iliazeus.vscode-ansi to show the rendered colors. Unfortunately it seems like there is no native support in the VSCode buffer view (microsoft/vscode#38834) so it would probably require effectively re-implementing what they've done in that extension to render the ANSI codes. Not sure how other editors might handle this kind of scenario, but for ones that do support rendering ANSI codes natively, a simple flag to switch between |
Other editors don't have this feature, and yes, I would expect us to implement ANSI code parsing and effectively transforming things into html or similar that we can emit in a colored fashion. |
We should bite the bullet and provide a |
Ye we should be able to provide the css there |
In the example of the above extension, they actually use a text decoration provider rather than any CSS/HTML output. I suppose if the intention is to eventually switch to a webview or something like that, the HTML/CSS would be fine, but for the existing editor implementation it would have to then translate from HTML to the VSCode text decoration API, right? Is there a significant different parsing ANSI codes (already available with cargo) vs HTML (not yet implemented)? |
Well there are two ways to solve this. Either via a normal text editor colored with decorators/custom syntax highlighting or via a webview that renders the html. |
I am interested in working on this and actually made some decent progress on a proof of concept, but I had some questions around licensing and whether this is actually the desired approach... I posted over on Zulip but haven't heard there so thought I'd repost on this issue to try and get some input here:
|
Sorry for not receiving any replies regarding this for so long. The ANSI approach seems fine to me, both approaches should be feature equivalent for our purposes. If there is no simple npm package that offers the relevant things we'd want here then copying from that extension seems fine imo, ideally keeping the copied parts in a separate ts file that we can put the license together (so a subdir in src) to make the licensing stuff clear there. That would also simplify removing that again should we move to the html output at some point. |
Cool! I ended up finding a small package that works well enough and basically rewrote everything I had been using from Edit: Oops I guess I should have done this sooner: @rustbot claim |
Thanks @Veykril for adding this nice feature in #13633! How hard would it be to use the same colors in the compiler diagnostic view that you also get when seeing the same error in the terminal?
The text was updated successfully, but these errors were encountered: