Ilya Bobyr <ilya.bo...@gmail.com> writes:
>>> + `<arg_hing>`, if specified, is used as a name of the argument in the
>>> + help output, for options that take arguments. `<arg_hint>` is
>>> + terminated by the first whitespace. When output the name is shown in
>>> + angle braces. Underscore symbols are replaced with spaces.
>> The last part is troubling (and sounds not very sane). Do we do
>> such a munging anywhere else, or is it just here? If the latter I'd
>> prefer not to see such a hack.
>
> The following commands have spaces in argument names in the "-h"
> output for one or two arguments:
> * clone
> * commit
> * merge
>
> A number of commands use dashes to separate words in arguments names.
That was not what I asked. I was asking if there is a precedent to
use "you cannot have underscores in hint; they will be turned into
spaces" quoting convention. I do not think of any (we either do a
backslash-quote, c-quote inside dq-pair, or %20, depending on the
context).
Personally, because these "hints" are not even hints (they are more
like placeholders for value that makes it easier to refer to in the
description of an option [*1*]), I wouldn't shed tears if scripted
Porcelains cannot use a space in the argh. In fact, it probably
makes the result harder to read and format more funnily if you had a
space in the argh string, be it in a subcommand implemented in C or
in a scripted Porcelain.
"An optional argh is terminated by a whitespace" is perfectly fine,
and by doing so we do not have to worry about having to introduce a
new quoting convention like you did, which is a big plus.
[Footnote]
*1* Perhaps like this:
--gpg-sign[=<key-id>]
Sign (with the key specified with <key-id>)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
