Add DisableColoredHelp setting to improve flexibility #2956
Conversation
|
bors r=ldm0 |
|
bors retry |
|
bors r- |
|
Canceled. |
pksunkara
force-pushed
the
disable-colored-help
branch
from
f4ca3c0
to
ac63c3c
Compare
|
For awareness to those not following; discussion is happening #2906 I'm going to catch up on that and give some feedback. |
src/build/app/settings.rs
Outdated
| #[cfg(feature = "color")] | ||
| DisableColoredHelp, |
There was a problem hiding this comment.
This wasn't behind a feature flag before, should it be now?
There was a problem hiding this comment.
This wasn't a setting before. This is a new setting which is inverted.
There was a problem hiding this comment.
That is just semantics, driven by our policy that a flag has to always represent the "true" state. Its us inverting an existing flag. The inverted form of this flag was not conditional.
There was a problem hiding this comment.
Yeah, the previous one wasn't gated because the macro didn't support gates on the settings until recently when I added them.
There was a problem hiding this comment.
So long as the feature gate is used in an additive manner (which it is here) I don't see a conflict.
|
"Final comment period" I'm good with merging this in support of making the v3 transition easier. Understood it's not the best way and that this will be changed in future versions as we tackle some of the trickier aspects of reflection and such. But having said that @epage are there any other objections that should keep us from moving forward on this as is, that haven't been expressed? My goal is to get these PRs cleared out to keep marching towards the release. |
|
The only remaining issue I had was for us to revert the feature gate on the setting. |
|
Yeah, we have been having discussion on this. We had already decided to not have feature gates on reflection API but have them on builder API. The issue here is that, this setting is both until the settings vs methods discussion is finalized. My proposal is to keep the feature gate in this scenario because the users we have more who look at the docs and get confused because this setting is a no-op without feature gate would be more than the users who would use this setting in the reflection API. |
|
I'm going to just make the tie breaking call that we remove the feature gate, but add in the docs that it's a hold over/no-op without the appropriate color cargo feature. You could even say something about how this feature will overhauled in future releases. This is the best compromise so we can make progress with this merge and readdress in the future. |
pksunkara
force-pushed
the
disable-colored-help
branch
from
ac63c3c
to
b02d1c5
Compare
) Until we have a modular help generator that can be configured and/or authored by the users themselves as part of #2914, we will provide the flexibility of turning off colored help messages but still wanting colored error messages. This flexibility was available before #2845 and @dbrgn immediately noticed it and requested it back to which I agree. This was also suggested by Josh in [here](clap-rs/clap#2806 (comment))
Add DisableColoredHelp setting to improve flexibility (clap-rs/clap#2956)
|
bors r+ I am merging since everyone agreed on the feature gate which was the last thing. |
|
Build succeeded: |
Until we have a modular help generator that can be configured and/or authored by the users themselves as part of #2914, we will provide the flexibility of turning off colored help messages but still wanting colored error messages.
This flexibility was available before #2845 and @dbrgn immediately noticed it and requested it back to which I agree. This was also suggested by Josh in here