This reduces the compile time for a non-incremental cargo check build by about 60%. It also reduces the amount of code and is easier to read because it uses standard Rust macros (concat and stringify) rather than a DSL.

Yansi uses parking_lot version 0.5, which is over 3 years old. Would it be possible to update it? I can see that the last update to Cargo.toml was a version bump, so I don't know if it would need to wait for something else?

TTY detection is on a per-stream basis, so a user will need to check stdout and stderr and then change their Style appropriately. yansi's "easy path" is to globally enable/disable color which won't take into account which stream the user is writing to, encouraging people to write incorrect code.

The link in the readme to the documentation goes to https://docs.rs/yansi/0.3.4/yansi/ , the resulting page says: "The requested resource does not exist"

For a CLI app, the user will need to support args and might have other constraints.

However, passing color information to a deeply nested crate can be impractical. For example, Someone might use mockall which uses predicates which uses difference, and difference wants to print colored diffs, where appropriate.

Alternatively, some times there isn't a good initialization point for a crate, like with tests. The above example is more likely to live in a test than in a bin.

Depending on the approach, this might be a counter example to #17.

Note: this is more brainstorming, I'm unsure how this will look.

Providing a default path for getting people to follow common practices

• Will help encourage people to do so
• Ensure people consistently implement the semantics (including precedence levels)

Common practices include:

• NO_COLOR support
• CLICOLOR / CLICOLOR_FORCE support
• Basic or advanced truecolor support detection
• TERM=dumb checks
• TTY detection
• Ensuring people call enable_windows_ascii and disable color when it fails ---color=<always|auto|never>

Since the CLI arg would involve integrating with another crate in the public API (like structopt / clap3), unsure whether that should be left to another crate to avoid coupling their breaking changes to yansi's.

Would you consider creating a crate with the docify macro? It's pretty clever and it's something I've needed before when writing helper macros but settled for just ignoring docs on functions created with the macro in that case.

Because new was the only constructor listed in the heading, I didn't check for a default and what it meant. It was only after digging through the source that I realized that this was an option and it did what I wanted (nothing).

When I use Rocket, cargo run meet this error

Compiling yansi v0.3.3
error[E0554]: #[feature] may not be used on the stable release channel
 --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/yansi-0.3.3/src/lib.rs:1:32
  |
1 | #![cfg_attr(feature="nightly", feature(const_fn))]
  |                                ^^^^^^^^^^^^^^^^^

error: aborting due to previous error

error: Could not compile `yansi`.

To learn more, run the command again with --verbose.

My system info: Microsoft Windows 7 Ultimate 64bit

Rust info: nightly-i686-pc-windows-gnu (default) rustc 1.21.0-nightly (f774bced5 2017-08-12)

Cargo.toml: yansi = "0.3.3"

main.rs: Paint::enable_windows_ascii(); print!("{} light, {} light!",
Paint::green("Green"), Paint::red("red").underline());

console output:

How to fix this problem?. this error occured when i try to install rocket

error[E0554]: #[feature] may not be used on the stable release channel --> $HOME/.cargo/registry/src/github.com-1ecc6299db9ec823/yansi-0.3.3/src/lib.rs:1:32 | 1 | #![cfg_attr(feature="nightly", feature(const_fn))] | ^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

error: Could not compile yansi. Build failed, waiting for other jobs to finish... error: build failed

thanks

• Migrate the crate to edition 2018
• Apply rustfmt and clippy to the code
• Migrate travis CI to GitHub Actions
• Add Style/Test/MSRV check into CI (Close #38)

Hi, and thanks for the library! I'm the maintainer of pretty_assertions, and am looking and moving from ansi_term to yansi. I couldn't find a documented MSRV, but the build failures point to 1.54.0 as a likely candidate (stabilization of extended_key_value_attributes).

This PR documents the MSRV and adds it to CI, along with a proposed policy (updating MSRV on minor versions is pretty standard I think?).

Let me know if you think this is okay, or if any updates are required. I'd like to know what your thoughts are on frequency of the MSRV being updated?

Basically, do the following automatically:

if !Paint::enable_windows_ascii() {
    Paint::disable()
}

The implementation should just check if painting is disabled via the already relaxed atomic bool and otherwise check a second atomic bool, also relaxes, to see if we've tried to enable Windows coloring already.

The main limitation is trait support (Default, ==, etc). Hopefully this subset is sufficient for most needs. The main thing I can see adding is a Style::plain since Style::default can't be used.

Fixes #16