Time for another open-source adventure! We’ll be joined by Max Jacobson as we visit the Rust cli-tool Tokei. Tokei generates statistics around your code and language usage. For example, chael.codes looks like: 
Forem, the repo behind therelicans.com and dev.to, looks like this: 
We’re going to pick up an issue with a lot of discussion that hasn’t been touched in 10 months that I personally like. Those screenshots before weren’t very engaging, right? Let’s add some lovely color to Tokei’s terminal output!
There are some requirements listed out in the issue above.
- It must look good in light and dark mode terminals
- A crate should manage colorizing the output
- A color flag should manage color output
--color (always|auto|never)- thick rows === should be bold and the thin rows — dimmed
I think it’d look nice to give all the languages a cyan color, and emphasize the subtotals.
First step is identifying how we’ll cover color output, and the issue points us to colored which is based on a Ruby gem of the same name. Usage is very straightforward. println!("Hello, {}!", "world".green().bold()) will use the terminal’s colors, and bold the text. 
Note that “cyan” or “green” may not always be cyan or green, they’re just roles in your terminal color scheme.
Next, it’s time to think about how and where to output these colors. Tokei implements a printer interface in cli_utils.rs which is where I found the headers!
With some lovely colors and style implemented in Tokei, it’s time to think about those command line args and turning off color. Some people (like other computers) prefer not to have color. I think we handle this in cli.rs. ShouldColorize respects environment variables like NOCOLOR and CLICOLOR, but flags seem helpful too. We should document this regardless.
Add Color to Tokei
#751
closes #419 Use the colored crate to add some additional color to Tokei. Colored will respect settings like CLICOLOR_FORCE and NO_COLOR. It will also use the configured terminal theme's blue.
| Old | New |
|---|---|
 |
 |
 |
 |
Top comments (6)
This looks really good, respecting the
NO_COLORandCLICOLOR, looking forward to the release.Thanks! It was a fun build too.
BTW. I meant to ask you how you handled the interaction between
CLICOLOR_FORCEandNO_COLOR. I then I found out the implementation is isolated to the colors crate, so I turned my attention to that release and did a small experiment and documented the result.I have created a PR for colors outlining this in the documentation.
Nice work! I love PRs that boost understanding like these. Do you do a lot of open-source PRs?
Yes, I try to contribute where I can.
Quite often it is related to documentation, because I find something hard to understand, explaining it to myself, might benefit others or if something is answered in an issue thread and I think it provides more value if promoted to the documentation.
I also write these Today I Learned notes (TIL) these sometimes, they end up as PRs or blog posts.
Well having fun is the most important part.
I did not know
NO_COLORbefore you mentioned it, onlyCLICOLORandCLICOLOR_FORCE. So now I am implementing it for one of my projects.If anybody reads this comment and think, what are they talking about, check out: