-
Notifications
You must be signed in to change notification settings - Fork 345
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hard to read custom options #87
Comments
I like the idea, but do you think the following solution might be better than adding a flag that hides the number print:
What do you think? Would that be general enough? |
I think this is general enough for my use case. At the moment I think it covers all possibilities for a custom input type. If it gets much more complex one should split it up in multiple options. Will you implement this or should I look at this? I'm not sure how much code needs to be changed for that. You mentioned the complex type. |
I don't think it would be that hard - very similar to what you've done already. A new |
everything should work as expected. Then only the help function needs to be changed. This also works for the description of |
I would store both values. I would not allow I think separating the two concepts (number of options vs number of items in an option) will make things simpler. |
Since it does show up in more places than I thought, I could start the patch, then you could fix the printing output? Would that work? |
Sorry for answering so late. Currently I'm very busy so I have no time to make big changes. What I wanted to say in the last post was: I have not enough time at the moment to do the big changes, but I can fix the output after you finished the patch. Or I try to implement it but this can take a while. |
It's more involved than I thought, but ultimately a good improvement, allowing some things I'm not fond of, like "unchangable", to be dropped. I've started a branch and will work on it occasionally. You are welcome to contribute if you see something that needs fixing (I'm giving you write access to my branch). I'll be amending the original comment for now, though, to keep the history clean. |
OK. Thanks for the write access. I will try to do something this week, but I cannot promise. |
Okay, I'm not sure how fast I'll be able to get anything done. My goal is to at least get the refactor working and tests passing, then maybe you can touch up the help printing? |
Sounds good. |
Added a simple test for what I assume you are doing, hope that's good enough... |
I'm really sorry that was absent the last two weeks. This looks perfectly fine. Thanks a lot. |
Hi,
I current experiment a little with CLI11 and tried to read a
std::pair<int, float>
as a custom option.All works fine. I used
set_custom_option("INT FLOAT", 2)
, to enforce that there are exactly two arguments and to reflect the types I expect. But the help text that is generated looks weird.It gets even worst if I also print default values (depends a little on how you stringify a pair).
I looked a while into the documentation and what methods are provided, but I couldn't find a solution to this.
So I took a quick look into the code and I added a quick fix for this. See the commit 1561a1a in my fork. If you are interested I can send a Pull Request.
But please let me know if I just didn't saw the right options.
Best,
Alex
The text was updated successfully, but these errors were encountered: