-
Notifications
You must be signed in to change notification settings - Fork 27
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
colors start at beginning of line instead of beginning of element #44
Comments
Hmm, you are quite right. I don't think I'll have time to look at this in the short term, but I'd be happy to accept a PR to fix the behavior! Glad you've been getting value out of the library. 😄 |
Thanks for the reply @greglook! It turns out the issue lays in fipp: brandonbloom/fipp#66. Under the kind guidance of @brandonbloom, I've submitted a PR: brandonbloom/fipp#69. Here's a preview of of puget with the updated fipp: I shall follow up here when the fipp PR has been merged and released. |
Fipp v0.6.21 now contains this fix. |
This is great, thanks @brandonbloom! I'll start on PR. I am noticing that there is little in way of ansi tests so I'll beef that up as part of verification along with fipp version bump. |
Bumped fipp to 0.6.21 to pick up brandonbloom/fipp#66 which resolves greglook#44. To verify, beefed up ansi unit tests to include a test that almost matches example in puget README and a test that clearly shows indentation. Of note: While developing these tests I used kaocha because it has excellent expected vs actual diff reporting. Because kaocha uses puget, I figured it might not be the best idea to use kaocha for puget testing and therefore have not proposed to include it.
Hello! First, thanks so much for puget, it is a wonderful library!
While experimenting with using background colors with puget, I noticed an interesting behavior.
If I
cprint
with the default:color-scheme
,I get similar results to the README screenshot:
But if I try background colors:
notice that the color starts at the beginning of the line rather than the beginning of the element:
A nested expression:
Illustrates the behavior more clearly:
I don't expect it would be terribly hard to start coloring at the beginning of an element rather than the beginning of the line. I am happy to take a crack at a PR if that would be helpful.
I noticed this while exploring coloring schemes here lambdaisland/deep-diff2#14
The text was updated successfully, but these errors were encountered: