You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 1, 2022. It is now read-only.
Currently, when one creates an application with arguments that specify environment variables via .env(), passing a flag that prints the program's help information at runtime will print environment variable information in the form: [env: NAME=], which is all expected.
The issue I wish to bring up arises when you add AppSettings::ColoredHelp (and have the corresponding feature enabled in your Cargo.toml). You'll notice that default values and possible values will be colorized, however the environment variables are not.
Expected Behavior Summary
This is more of a minor nitpick I suppose. I would expect NAME= or NAME in the [env: NAME=] substring to be colorized like how VAL in [default: VAL] is colorized.
The text was updated successfully, but these errors were encountered:
Comment by pksunkara Tuesday Apr 14, 2020 at 22:03 GMT
I actually removed the colorizing for default values and possible values and aliases in #1824. I wanted to rethink quite a bit on how to display this stuff while also taking #1695 into account. I am renaming this issue.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Issue by HarrisonTotty
Monday Apr 22, 2019 at 19:29 GMT
Originally opened as clap-rs/clap#1456
Rust Version
Affected Version of clap
Bug or Feature Request Summary
Currently, when one creates an application with arguments that specify environment variables via
.env()
, passing a flag that prints the program's help information at runtime will print environment variable information in the form:[env: NAME=]
, which is all expected.The issue I wish to bring up arises when you add
AppSettings::ColoredHelp
(and have the corresponding feature enabled in yourCargo.toml
). You'll notice that default values and possible values will be colorized, however the environment variables are not.Expected Behavior Summary
This is more of a minor nitpick I suppose. I would expect
NAME=
orNAME
in the[env: NAME=]
substring to be colorized like howVAL
in[default: VAL]
is colorized.The text was updated successfully, but these errors were encountered: