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

fix: Match rustc's colors #73

Merged
merged 1 commit into from
Jan 4, 2024
Merged

Conversation

Muscraft
Copy link
Member

@Muscraft Muscraft commented Jan 2, 2024

This PR makes it so that we match rustc's output regarding colors. See here and here for rustc's current color implementation.

Note: Where rustc uses set_intense(true), that is the same as Bright<color> in anstyle.

Note: Most things are BOLD as rustc eventually sets most things bol (see the first link).

Comment on lines 65 to 69
const BRIGHT_BLUE: Style = if cfg!(windows) {
AnsiColor::BrightCyan.on_default().effects(Effects::BOLD)
} else {
AnsiColor::BrightBlue.on_default().effects(Effects::BOLD)
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: as this isn't just bright blue, lets move the .effects call down below

} else {
AnsiColor::Yellow.on_default().effects(Effects::BOLD)
},
info: BRIGHT_BLUE,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does info map to in rustc? No level uses BRIGHT_BLUE. Is it a Secondary?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should map to UnderlineSecondary or LabelSecondary, but annotate-snippets doesn't have the concept of primary/secondary, so we print info: before it currently.

Comment on lines 73 to 76
warning: if cfg!(windows) {
AnsiColor::BrightYellow.on_default().effects(Effects::BOLD)
} else {
AnsiColor::Yellow.on_default().effects(Effects::BOLD)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: should we have .effects be outside of the if expression?

@zbraniecki
Copy link
Contributor

My slight preference would be to externalize platform-specific settings to some options bag parameter like "use_cyan" and set it in constructor to true for windows in the binary.

This makes it easier for a customer to replicate the same color scheme as windows has in other environments without having to emulate windows cfg.

line_no: AnsiColor::BrightBlue.on_default().effects(Effects::BOLD),
emphasis: Style::new().effects(Effects::BOLD),
line_no: BRIGHT_BLUE,
emphasis: if cfg!(windows) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I'm reading this correctly, this maps to MainHeaderMsg? What about Highlight?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct, emphasis maps to MainHeadingMsg. As for Highlight annotate-snippets doesn't currently have anything for that concept (that I can tell).

Comment on lines 83 to 89
AnsiColor::BrightWhite.on_default().effects(Effects::BOLD)
} else {
Style::new().effects(Effects::BOLD)
},
none: Style::new(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: should .effects be on the outside of the if?

@epage
Copy link
Contributor

epage commented Jan 2, 2024

My slight preference would be to externalize platform-specific settings to some options bag parameter like "use_cyan" and set it in constructor to true for windows in the binary.

This is all themable so they can do what they wish.

For myself, my preference is that the agreed-to cross-Rust-project behavior be the default here so we don't have to worry about what feature flags and constructor parameters we need to keep in sync

@Muscraft
Copy link
Member Author

Muscraft commented Jan 3, 2024

The goal for this change is to be as close to rustc as possible by default. Having to tell annotate-snippets that you need Windows-specific colors seems to step away from this idea, as a user would not be getting the same colors as rustc by default. This also makes the API slightly more complicated and would require a user to know that they need to call use_cyan() (or similar) on Windows to get the correct colors for their platform.

@Muscraft Muscraft changed the title chore: Match rustc's colors fix: Match rustc's colors Jan 4, 2024
@Muscraft Muscraft merged commit 77a3f08 into rust-lang:master Jan 4, 2024
13 checks passed
@Muscraft Muscraft deleted the rustc-colors branch January 4, 2024 21:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants