mentalisttraceur
commented
5 months ago I'm going to close this myself, actually. That way if there's interest y'all can reopen it, but if not that's one less thing for you to do. (I think just seeing an issue like this, with the pro/cons laid out, would've addressed what I was looking for, so hopefully this helps someone else like me in the future.)
epage
Please complete the following tasks
Clap Version
any/future
Describe your use case
Some people prefer to separate short/long/alias options with just a space:
..instead of a comma and a space:
I'm personally undecided which way is Better(tm) or that the difference matters enough to support both, but I couldn't find any issue/discussion for it so I wanted to at least create an issue to capture any decision/rationale.
Describe the solution you'd like
Maybe just this issue existing as-is with a wontfix, if that's the decision.
Or a boolean, somewhere. (I don't yet have enough Rust experience to have opinions/preferences about where.)
Or even let people pass a custom separator string to override the
", ". For example, some people might strongly feel that two spaces (with or without a comma) improves readability even more.Alternatives, if applicable
Getting over it. Having an epiphany that ", "-separation is better actually.
I don't think the Rust program which is using
clapcan do anything (unless there's more capability than I know about to monkey-patch/hook/intercept stuff)? Seems like at best someone would have to intercept the string once it has already been formatted, in a separate process, and try to delete only the correct separator commas (as opposed to any that are in the prose, such as in option descriptions).Additional Context
Over the year I've noticed both used by command-line tools. For example, Docopt supports both - the first example on the Docopt website does space-only, the second does comma+space.
The tradeoffs are small either way. It can be simpler to mechanically parse the space-only way: the most basic of split-by-whitespace will do it, without needing to then check for and trim off the
,- but any serious help-text parser would have to handle both variants anyway. It saves one character, but that only barely matters to a small minority of people who regularly use CLIs on their phones or tightly split their screen real-estate vertically.The comma sometimes seems to help me with visual parsing, other times it feels like it just adds visual noise. When there's whitespace below the comma and the characters right before it don't poke below the line ("p", "q", "j", "y"), the comma is visually distinct in a way that sometimes sticks out to me even when scrolling or when my eyes are focused on something else in the area. I do think that in the common/general case, the comma helps visual parsing.
Another benefit is that the meaning of a comma is extremely clear, it might help interpretation for those not yet familiar with CLI help text conventions.