Replies: 5 comments 17 replies
-
|
First, I want to say, thank you for providing feedback! As discussed in #2806, we had user confusion from people assuming turning on color would turn it on everywhere. Something that might not have been mentioned is that we are also trying:
|
Beta Was this translation helpful? Give feedback.
-
Could you help me understand why |
Beta Was this translation helpful? Give feedback.
-
|
The help page is something you'll see often, essentially any time you want to look up how the API works. To me, the help page is part of the regular CLI. The errors on the other hand are purely informational and I don't mind colors. I'm not sure I have rational arguments, but somehow colored help pages feel distracting while colored error messages seem appropriate 😄 |
Beta Was this translation helpful? Give feedback.
-
Huh, thanks for sharing! For me, I see the errors much more often than help :)
I fully understand that! :) |
Beta Was this translation helpful? Give feedback.
-
For this one, I think we should first be focusing on how we can improve the existing colored help. For example, maybe less color and careful placement of bold (help headings), dimmed (parenthetical statements ( If we find we can't take the feedback from different sources and come to a "good enough" result for everyone, I think thats then the time to consider adding in a |
Beta Was this translation helpful? Give feedback.
-
I disagree with this. We want to modernize CLIs, not dumb them down in order to avoid just one more app setting. |
Beta Was this translation helpful? Give feedback.
-
|
I do not see how those are a dichotomy and I do not see how my comment is counter to modernizing CLIs. My comment is looking for input for us to polish our colored output. I do not think we are at an ideal state. Honestly, the output and code comes across as implementation convenience. For example we are reusing formatting defined for error reporting (e.g. |
Beta Was this translation helpful? Give feedback.
-
Agree. But the way you phrased your comment gave off the intention that you wanted to go back to grayscale help text which I disagree with in particular. |
Beta Was this translation helpful? Give feedback.
-
|
I was trying to foster brainstorming by mentioned examples of alternative approaches for individual pieces, rather than a coherent full recommendation. |
Beta Was this translation helpful? Give feedback.
-
|
This conversation is continued in #2963 |
Beta Was this translation helpful? Give feedback.
-
|
As a future workaround for this, one of the things we've been talking about is a more modular clap. One specific idea I've had is that we add a general reflection API. One user of that API would be a help builder API. We could then reuse help generation between Once we support this, you could then create custom help generation. Taking that a step further, help is pretty static (except text width, as long as you don't have runtime defaults). What if we supported a way to code-gen the help and and disable the runtime help generation, reducing binary bloat. This would not be available at release of clap3, so one option is to have a |
Beta Was this translation helpful? Give feedback.
-
|
Agree with all this. But I still think we should add |
Beta Was this translation helpful? Give feedback.
-
|
btw I've created #2913 and #2914 for the long term idea.
I'd like to see how the polish conversation goes before we make a decision on this. I am hopeful we can come to an even better solution than we have today.
I disagree with this. We have to step back every once in a while and re-evaluate the organic growth for where we can streamline or outright trim. I think our validator conversation and my recommendation for MultiCall are example of this. |
Beta Was this translation helpful? Give feedback.
-
I agree we need it but I don't think we can do the design before v3 which is why I saw suggesting to temporarily add a setting. |
Beta Was this translation helpful? Give feedback.
-
|
If |
Beta Was this translation helpful? Give feedback.
-
|
It would get deprecated when #2914 is complete, but removed in v4. Is the churn worth it? My general thoughts are we should be biased towards less churn, but evaluate each on it's individual merits. My thinking here is that I can't force anyone to spend their time on the longer term solution here, so I don't actually know when it'll be completed but I'd be quite shocked if it's ready to go in less than three months (especially since I don't see it as a v3 blocker). Now if someone wants to spend their time knocking it out, awesome! I just can't force someone to do so, and it's a large enough issue that I think there are still plenty of design related questions prior to even getting the actual code out. So in this particular case, the temporary API is small enough and the better solution far enough out that I'm less worried about churn. But like I always say; I'm open to arguments against that logic. Edit: clarity |
Beta Was this translation helpful? Give feedback.
-
|
I agree that it's…I hate to say ugly, but certainly with my terminal colors it is.
I'm very surprised there is no flag like …
let mut sc = dash::clap_app();
let mut argparser = App::new("MFEKpathops")
.setting(AppSettings::SubcommandRequired)
.setting(AppSettings::DisableVersionFlag)
.setting(AppSettings::DisableHelpSubcommand)
.author("Fredrick R. Brennan <copypasteⒶkittens⊙ph>; MFEK Authors")
.about("A utility for applying stroking techniques to contours (in UFO .glif format).");
let argparser_sc = argparser.clone().subcommand(sc.clone());
let cc = if let Err(e) = argparser_sc.clone().try_get_matches() {
if e.kind == clap::ErrorKind::DisplayHelp {
clap::ColorChoice::Never
} else {
clap::ColorChoice::Auto
}
} else {
clap::ColorChoice::Never
};
sc = sc.color(cc);
argparser = argparser.color(cc).subcommand(sc);
let matches = argparser.get_matches();
…I'm interested in the result of this discussion because this is an equally ugly hack (in the service of the removal of ugliness to users, I suppose I must sustain some myself 😄). |
Beta Was this translation helpful? Give feedback.
-
|
We have #2956 which will add a If its just a question of not looking good or not, I'd recommend to instead participate in making it better over at #2963 so we can have a prettier / more universally applicable view. |
Beta Was this translation helpful? Give feedback.
-
|
Just wondering, what's the problem with not wanting colored help at all, no matter how well-tuned the colors are? |
Beta Was this translation helpful? Give feedback.
-
|
For me it's primarily a question of how it looks, for others it might not be. |
Beta Was this translation helpful? Give feedback.
-
|
@dbrgn in case you are asking "why get make it unconfigurable?" Each feature in clap comes at a cost that is a mixture of
I personally have not noticed many features in clap because of how overwhelmingly large the API is. I think the model of "Let a 1,000 flowers bloom. Then rip 999 of them out by the roots." applies well to clap and I feel we are at a phase that we should be looking to rip flowers out, either directly or by providing instead providing general building blocks to let users do it more manually. I'm trying to understand the value of being able to disable colored help, independent of other coloring in clap, to justify it being in the API. |
Beta Was this translation helpful? Give feedback.
-
|
I decided to ask myself “what color is actually important to me that it remains for my users?” and the only one is the red bold https://github.com/MFEK/glif/blob/master/src/util/mod.rs#L52-L90 pub fn set_panic_hook() {
set_hook(Box::new(|info| {
let msg = info.payload().downcast_ref::<&str>();
if let Some(info) = msg {
eprintln!("\n{}\n", info.bright_red());
} else {
eprintln!("\n{}\n", info.to_string().bright_red());
}
let err = msgbox::create(
"Uh oh! \u{2014} MFEKglif crashed",
info.to_string().as_str(),
IconType::Error,
);
… |
Beta Was this translation helpful? Give feedback.
-
@dbrgn
(split out from #2845)
Beta Was this translation helpful? Give feedback.
All reactions