Comments (3)
I don't think we should make any decisions for the user here. They should be able to (or be able not to) conform to any standard or non-standard they want. But I don't quite understand your example. Can you be specific, perhaps with code?
from yansi.
Let's break apart the users involved
- User running a program
- Program author
- Test crate author
Ultimately, the color policy is left for the program author to decide but generally will follow a standard the user running the program expects.
Now, a crate author might try to make testing easier, and want colored output to help, like pretty_assertions. The program author would then be using this as part of their testing. The user running the program never sees this.
Options for test tool crates, like pretty_assertions
- Hard code colors on
- Put colors behind a feature flag
- Use a
once_cell
to call color detection code and store the value
Rather than every test crate handling this on their own, what if we provided a feature flag that had logic from #18 in it and would ensure we do the "right thing" in these cases.
from yansi.
I don't think conforming to a variety of standards should be yansi
's prerogative. I don't want yansi
to be opinionated here: I want it to fit every use-case. If another crate wants to provide utilities that conform to these standards, then that's totally great. But I think we should leave it to other crates.
from yansi.
Related Issues (20)
- Bright colors? HOT 6
- Implement standard traits for Style HOT 3
- Update docs to call out `Default` constructor for Style HOT 2
- API to constrain a `Style` from truecolor to basic colors HOT 3
- const-fn the API HOT 2
- Global enable/disable encourages the wrong behavior HOT 4
- Encourage colored-output common practices HOT 3
- Add hyperlink style support HOT 6
- Add a feature flag to automate Windows coloring HOT 6
- Version 1.0? HOT 2
- Used parking_lot version is quite old HOT 5
- Cannot build/compile from source HOT 1
- Impl `{Upper,Lower}Hex` for `Paint` HOT 1
- The method `clear` in trait `Paint` causes a conflict with `Vec::clear` HOT 4
- FR: Implement `AsRef<str>` for `Painted<&str>`
- Allow conditions to accept closures HOT 2
- The method `Paint::clear` breaks the project when using `String.clear` HOT 3
- Automatic disabling when stdout/stderr is not a terminal. HOT 1
- Docify crate HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from yansi.