René Scharfe <l....@web.de> writes:
> We could check if argh comes with its own angle brackets already and
> not add a second pair in that case, making PARSE_OPT_LITERAL_ARGHELP
> redundant in most cases, including the one above. Any downsides?
> Too magical?
Hmph.
> -- >8 --
> Subject: [PATCH] parse-options: automatically infer PARSE_OPT_LITERAL_ARGHELP
>
> Avoid adding an extra pair of angular brackets if the argh string
> already contains one. Remove the flag PARSE_OPT_LITERAL_ARGHELP in the
> cases where the new automatic handling suffices. This shortens and
> simplifies option definitions with special argument help strings a bit.
>
> Signed-off-by: Rene Scharfe <l....@web.de>
> ---
> { OPTION_STRING, 0, "prefix", &opts.prefix,
> N_("<subdirectory>/"),
> { OPTION_CALLBACK, 'g', "reflog", &reflog_base,
> N_("<n>[,<base>]"),
> N_("<mode>,<object>,<path>"),
> + OPT_STRING(0, "prefix", &prefix, N_("<prefix>/"),
Hmph.
> diff --git a/parse-options.c b/parse-options.c
> index 7db84227ab..fadfc6a833 100644
> --- a/parse-options.c
> +++ b/parse-options.c
> @@ -660,7 +660,8 @@ int parse_options(int argc, const char **argv, const char
> *prefix,
> static int usage_argh(const struct option *opts, FILE *outfile)
> {
> const char *s;
> - int literal = (opts->flags & PARSE_OPT_LITERAL_ARGHELP) || !opts->argh;
> + int literal = (opts->flags & PARSE_OPT_LITERAL_ARGHELP) || !opts->argh
> ||
> + (opts->argh[0] == '<' && strchr(opts->argh, '>'));
You are greedier than what I thought ;-) I would have limited this
magic to the case where argh is surrounded by "<>", but you allow
one closing ">" anywhere, which allows us to grab more complex cases.
The lack of escape hatch to decline this auto-literal magic makes me
somewhat nervous, but I do not offhand think of a reason why I do
want an arg-help string that _begins_ with '<' to be enclosed by
another set of "<>", so perhaps this is a good kind of magic.
