-
Notifications
You must be signed in to change notification settings - Fork 83
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
error-stack
: introduction of color modes
#1800
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
the
area/libs > error-stack
Affects the `error-stack` crate (library)
label
Jan 11, 2023
Codecov Report
@@ Coverage Diff @@
## main #1800 +/- ##
==========================================
+ Coverage 57.05% 57.27% +0.22%
==========================================
Files 261 265 +4
Lines 18700 18802 +102
Branches 421 421
==========================================
+ Hits 10669 10769 +100
- Misses 8026 8028 +2
Partials 5 5
Flags with carried forward coverage won't be shown. Click here to find out more.
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
indietyp
requested review from
TimDiekmann,
Alfred-Mountfield and
thehabbos007
January 11, 2023 19:30
TimDiekmann
previously approved these changes
Jan 30, 2023
❌ This pull request failed tests. It has been removed from queue. (details) |
/trunk merge |
trunk-io bot
pushed a commit
that referenced
this pull request
Jan 30, 2023
## 🌟 What is the purpose of this PR? In various PR the Rust CI linting job is failing as `cargo make` is supposed to be installed, but it's not. This PR tries to solve this by not caching the tools (which is probably a good idea anyway). If this PR is able to be merged, this issue should be solved, otherwise, it's very likely hitting the same bug. ## 🔗 Related links This error happened in - #1800 - #1973 - #1976
TimDiekmann
approved these changes
Jan 30, 2023
trunk-io bot
pushed a commit
that referenced
this pull request
Jan 30, 2023
## 🌟 What is the purpose of this PR? We have a logic in place to only run a subset in PRs and only run the full set of tests before merge. However, in order to test locally, this logic should be reversed and instead of testing for a `push` event, this should test for `pull_request` events. ## 🔗 Related links - #1800
😎 Merged successfully (details). |
trunk-io bot
pushed a commit
that referenced
this pull request
Jan 31, 2023
## 🌟 What is the purpose of this PR? Remove `owo-colors` as a dependency. This means we can push the enable `colors` support without an extra feature! `owo-colors` is being replaced with a vendored solution that does the same thing, only more correct. This also implements the suggestion from #1800 (comment) ### Why remove `owo-colors`? Don't get me wrong, `owo-colors` is a great crate, but for our purposes is a bit too heavy. Initially, we chose `owo-colors` because of the convenience, and we thought that it might provide Windows support (my bad 😅) and automatic detection of color support. In 0.3, we have removed automatic detection support and discovered that `owo-colors` does not - in fact - provide Windows support. In that case, it is pretty easy to create an alternative with a similar level of convenience, and after going on an adventure 🥾 with @TimDiekmann through the lands of Windows 11 terminals and discovered that pretty much every built-in terminal either supports ANSI escape sequences natively out-of-the-box, or it can be enabled (on older installations). ### Correctness of `owo-colors` What about correctness? After looking through snapshots I have discovered that for style attributes like `bold` or `italic` `owo-colors` actually does the wrong thing when resetting the styles. I will be posting a follow-up PR for `owo-colors`, but due to it being passively maintained I think there's a low chance it will be in time for 0.3 anyway. ![image](https://user-images.githubusercontent.com/7252775/215569683-2bf9bd12-7076-4fcc-a7c1-f2c2b3545767.png) The problem: when using style attributes like `bold` (`\e[1m`) or `italic` (`\e[3m`) when you want to end the portion of text there are two options: 1) nuclear: `\e[0m`, this removes all formatting (`owo-colors` uses this) 2) 🎩 gentleman: `\e[22m` (not `bold`), `\e[23m` (not `italic`), instead of removing and resetting everything it just disables bold or italic respectively, allowing for nested styles and even colored text in italic text (not possible with the nuclear option) We also compress as much as possible, meaning that `bold italic` is not `\e[1m\e[3m` but instead `\e[1;3m`. Small optimization, but a nice one c: ## 👂 Open Questions I went ahead and just implemented all ANSI escape sequences, they are currently lacking tests (coming soon), but most are currently unused. Should we remove the ones that are not needed or future-proof the solution? Do we want to expose the coloring methods through `error-stack`? > IMO, no, if we want to go ahead with something like that, it should go in a separate crate ## 🔗 Related links ## 📹 Demo
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
🌟 What is the purpose of this PR?
This implements the notion of color modes, determining if colors and which type of coloring/styling are requested.
This enables users to override the preferred mode while preserving the convenience of environment variables likeThis has been moved into an example.NO_COLOR
andFORCE_COLOR
.The available color modes are
Color
,None
, andEmphasis
. This mode is available for hooks so that they can easily adapt. A perfect example of this is the location hook, which now will use themode
to either print in bright black or italic.If no color mode is set, the mode is automatically determined usingIf no color mode is set, the mode is set toowo-colors
usingsupports-colors
and the specified override.Color::Emphasis
if thecolor
feature (opt-in) is enabled.🔗 Related links
🔍 What does this change?
Report::format_color_mode_preference
HookContext::mode()
is now available📜 Does this require a change to the docs?
Yes, the new
ColorMode
needs to be explained. This is already done.We might want to add additional explanation/info in
lib.rs
🏃 Next Steps
🛡 What tests cover this?
📹 Demo