Re: [PATCH 2/3] parse-options: add PARSE_OPT_CUSTOM_ARGH for complicated argh's

Stephen Boyd [off-list ref] writes:

If argh is complicated, i.e. the option takes more than one argument,
don't add the brackets around argh in the usage message.

I think later user wants a bit more descriptive explanation, like...

	Usually, argh element in struct option points at a placeholder
	value (e.g. "val"), and this is used to show

	    --option=<val>

	by enclosing the string inside of angle brackets.

	When the option takes something more complex (e.g. optional part
	separated by comma), you would want to produce a help that looks
	like

	    --option=<val1>[,<val2>]

	In such a case, the caller can pass a string to argh with
	placeholders already enclosed in necessary angle brackets
	(e.g. "<val1>[,<val2>]") and set this option.

Please update Documentation/technical/api-parse-options.txt as well.

Junio C Hamano wrote:

Stephen Boyd [off-list ref] writes:

quoted

If argh is complicated, i.e. the option takes more than one argument,
don't add the brackets around argh in the usage message.

I think later user wants a bit more descriptive explanation, like...

	Usually, argh element in struct option points at a placeholder
	value (e.g. "val"), and this is used to show

	    --option=<val>

	by enclosing the string inside of angle brackets.

	When the option takes something more complex (e.g. optional part
	separated by comma), you would want to produce a help that looks
	like

	    --option=<val1>[,<val2>]

	In such a case, the caller can pass a string to argh with
	placeholders already enclosed in necessary angle brackets
	(e.g. "<val1>[,<val2>]") and set this option.

This description sounds nice ;) Is PARSE_OPT_CUSTOM_ARGH a good name? I
was thinking maybe PARSE_OPT_MULTARGS is better?

Please update Documentation/technical/api-parse-options.txt as well.

There's no documentation on the flags yet, but I suppose I could add that.