-
-
Notifications
You must be signed in to change notification settings - Fork 338
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
feat: accept Color and Modifier for all Styles #720
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #720 +/- ##
======================================
Coverage 92.1% 92.1%
======================================
Files 48 48
Lines 14367 14511 +144
======================================
+ Hits 13238 13378 +140
- Misses 1129 1133 +4 ☔ View full report in Codecov by Sentry. |
PR Notes: this is a large-ish PR, but it's repetitive. It does have me wishing that we could macro up the setters though to remove the duplication. |
All style related methods now accept `S: Into<Style>` instead of `Style`. `Color` and `Modifier` implement `Into<Style>` so this is allows for more ergonomic usage. E.g.: ```rust Line::styled("hello", Style::new().red()); Line::styled("world", Style::new().bold()); // can now be simplified to Line::styled("hello", Color::Red); Line::styled("world", Modifier::BOLD); ``` Fixes #694 BREAKING CHANGE: All style related methods now accept `S: Into<Style>` instead of `Style`. This means that if you are already passing an ambiguous type that implements `Into<Style>` you will need to remove the `.into()` call. `Block` style methods can no longer be called from a const context as trait functions cannot (yet) be const.
Adds conversions for various Color and Modifier combinations
Rebased on #721 to fix conflicts with the buffer module refactor. |
Fixed PR lint |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just have a few interrogations. From
impl should simplify common usage imo, I'm wondering if some of them here are not too ambiguous.
All style related methods now accept
S: Into<Style>
instead ofStyle
.Color
andModifier
implementInto<Style>
so this is allows formore ergonomic usage. E.g.:
Fixes #694
BREAKING CHANGE: All style related methods now accept
S: Into<Style>
instead of
Style
. This means that if you are already passing anambiguous type that implements
Into<Style>
you will need to removethe
.into()
call.Block
s with styles can no longer be created in a const context astraits do not yet support const functions.