Skip to content
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

Add the markdown preview for the output of rustc --explain E... #63128

Closed
XVilka opened this issue Jul 30, 2019 · 9 comments
Closed

Add the markdown preview for the output of rustc --explain E... #63128

XVilka opened this issue Jul 30, 2019 · 9 comments
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@XVilka
Copy link

XVilka commented Jul 30, 2019

Currently it outputs the raw markdown, but it makes sense to provide an embedded preview. Luckily, there is an amazing Rust library for that - termimad.
And it is scrollable out of the box.

image
image

@jonas-schievink jonas-schievink added C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 30, 2019
@Mark-Simulacrum
Copy link
Member

I think there's a fairly high cost to this for relatively little gain. Rendering the markdown means that the compiler itself gains fairly hefty dependencies in a markdown parser and terminal printing (currently limited to rustdoc, for the most part). It also makes it much harder to copy/paste the code as it's now indented and potentially colored, as well as it looks like asking the compiler to implement TUI-like scrolling and such. Today's solution of "just dump some text to the command line" is considerably easier, IMO.

@XVilka
Copy link
Author

XVilka commented Jul 30, 2019

Maybe some simple integration then? With configuration option that it can pipe to something like that automatically? Basically executing the external binary. Should be very easy to implement and no deps required.

@Mark-Simulacrum
Copy link
Member

What does that gain over rustc --explain ... | <tool> or an alias on the command line that does that? I guess to an extent the reason why I'm pushing back might be that I personally almost never look at explain on the command line (or anywhere, really) so it's hard for me to judge the frequency of use. Configuration doesn't really work either because rustc doesn't have any configuration not passed to it via command line flags...

Maybe a reasonable solution here is to write a crate, e.g. rustc-explain that could be called cargo installd that would invoke rustc internally to get the output? That way iteration and such would also be faster.

@XVilka
Copy link
Author

XVilka commented Jul 30, 2019

Yes, creating such a crate might be a good idea, agree.

@Mark-Simulacrum Mark-Simulacrum added C-feature-request Category: A feature request, i.e: not implemented / a PR. and removed C-enhancement Category: An issue proposing an enhancement or a PR with one. labels Jul 30, 2019
@Mark-Simulacrum
Copy link
Member

I'm going to close this -- the external crate idea seems reasonable and if it gains traction we can re-explore adding it to the compiler in some fashion.

@pickfire
Copy link
Contributor

pickfire commented Nov 4, 2020

@XVilka Did you found any alternatives? Or even cargo explain? Oh, I just realized it is a thing https://crates.io/crates/cargo-explain

@tgross35
Copy link
Contributor

tgross35 commented Nov 15, 2022

@Mark-Simulacrum would a PR possibly be accepted that does very simple markdown parsing? Nothing complex with external dependencies, just use termcolor (already a dep) to add a background color to backticked blocks, and bold/italic/underlines # sections

@tgross35
Copy link
Contributor

The parser could even be regex, I quickly tested and the following work:

const CODE_BLOCK: &str = r#"```((?s).*?)```"#;
const CODE_INLINE: &str = r#"`((?s).*?)`"#;
const HEADING1: &str = r#"^#{1}\s+(.*)"#;
const HEADING2: &str = r#"^#{2}\s+(.*)"#;
const HEADING3: &str = r#"^#{3}\s+(.*)"#;
const HEADING4: &str = r#"^#{4}\s+(.*)"#;
const BOLD: &str = r#"\*\*((?s).+?)\*\*"#;
const ITALIC: &str = r#"_((?s).+?)_"#;
const LIST: &str = r#"^[-*]\s(.*?)$"#;

First step would just be to replace these with asymmetric HTML-style tags e.g. <codeblock>...</codeblock>, <bold>...</bold>. Then, iterate through and write to the buffer, change the termcolor output whenever one of those tags is hit.

It wouldn't work for anything super complex, but this would still provide much nicer output than the current raw markdown.

@tgross35
Copy link
Contributor

Ok, I have a very simple working implementation, only 150 lines of code. All that should be needed are calls to termcolor

Gist: https://gist.github.com/5e53ccff274bf7f66e7e8aec5375eda3

Once I figure out where this would belong I'll open a PR

bors added a commit to rust-lang-ci/rust that referenced this issue Jul 5, 2023
Add simple markdown formatting to `rustc --explain` output

This is a second attempt at rust-lang#104540, which is rust-lang#63128 without dependencies.

This PR adds basic markdown formatting to `rustc --explain` output when available. Currently, the output just displays raw markdown: this works of course, but it really doesn't look very elegant. (output is `rustc --explain E0038`)

<img width="583" alt="image" src="https://github.com/rust-lang/rust/assets/13724985/ea418117-47af-455b-83c0-6fc59276efee">

After this patch, sample output from the same file:

<img width="693" alt="image" src="https://github.com/rust-lang/rust/assets/13724985/12f7bf9b-a3fe-4104-b74b-c3e5227f3de9">

This also obeys the `--color always/auto/never` command option. Behavior:

- If pager is available and supports color, print with formatting to the pager
- If pager is not available or fails print with formatting to stdout - otherwise without formatting
- Follow `--color always/never` if suppied
- If everything fails, just print plain text to stdout

r? `@oli-obk`
cc `@estebank`
(since the two of you were involved in the previous discussion)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants