-
Notifications
You must be signed in to change notification settings - Fork 418
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
Add support for custom paramLabel #441
Comments
The paramLabel is repeated for every arity by design: This explains to the end user how many parameters they need to supply. You can supply a custom synopsis if the auto-generated synopsis becomes too detailed. Can you show an example of why this doesn’t work well for your application? |
Thanks for that example, now I understand. It looks like what you really need is Composite Parameters (#358). I will look into how easy it would be to provide a Meanwhile, let's take another look at what you can do now. Starting with For the email this could be The With future versions of picocli (when Composite Parameters (#358) are supported), users could leave off the quotes. |
Thanks for thinking with me here Remko, I really appreciate it. Picocli is pretty great.
If I could reduce all parameters to single-value parameters, we wouldn't have this discussion in the first place :) So that's a no go. I have so many possible options and variations (it's much more than just configuring from and replyTo addressess), splitting them up is going to explode the possibilities into a complete mess. The only way this would work with OptionSpec type String is with the following usage: See how quickly that becomes messy? And that's just for using it, extracting the three arguments is messy too, since the token separators are not straightforward; sometimes it's a set of quotes, sometimes it's a space, but only if it doesn't occur in a set of quotes. As you say, I really need Composite Parameters. Or a customParamLabel. |
Understood. Thanks for the clarification. |
…ntry and taking into account separator instead of using hardcoded space " "
…nd taking into account separator instead of using hardcoded space " "
…s` annotations; javadoc; remove commented out code Still TODO: add unit tests for configuring usage help with hideParamSyntax via annotations
I merged the PR. Thanks for the contribution! I will close this ticket after adding some unit tests for configuring usage help with hideParamSyntax via annotations. I started to think about Composite Parameters some more. I want to make sure that the resulting solution covers your use case. Let's continue that discussion on ticket #358. |
Was this in a release yet? Couldn't find it. |
Yes. In 3.6. Enjoy! |
Details are in the release notes: Thanks again for the contributions! |
Ok so I have almost everything sorted out, except for one limitation.
Here's what I'm using currently to define an OptionSpec:
This is working well for me, except that for every arity the paramLabel is repeated.
The only way to currently solve this, is by defining the type as String with an arity of 0 or 1 depending on whether there are parameters at all or not:
This solves the paramLabel issue, but now I have an even bigger problem, because now I need to manually extract the param tokens from the single string parameter. This is rather complex, since whitespace can be a separator as well as a valid value (you would know!).
What would make the entire solution work for me if I could do the following:
customParamLabel then would be used as-is without repeating.
What do you think?
The text was updated successfully, but these errors were encountered: