All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Ilya Bobyr <ilya.bobyr@gmail.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
	Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: [PATCH v3] rev-parse --parseopt: option argument name hints
Date: Thu, 20 Mar 2014 11:38:17 -0700	[thread overview]
Message-ID: <xmqqpplgyaud.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1395305092-1928-1-git-send-email-ilya.bobyr@gmail.com> (Ilya Bobyr's message of "Thu, 20 Mar 2014 01:44:52 -0700")

Ilya Bobyr <ilya.bobyr@gmail.com> writes:

> Built-in commands can specify names for option arguments when usage text
> is generated for a command.  sh based commands should be able to do the
> same.
>
> Option argument name hint is any text that comes after [*=?!] after the
> argument name up to the first whitespace.  Underscores are replaced with
> whitespace.  It is unlikely that an underscore would be useful in the
> hint text.
>
> Signed-off-by: Ilya Bobyr <ilya.bobyr@gmail.com>
> ---
>  Changed according to the last comments.  Added "Usage text" paragraph in the
>  documentation and updated variable names.
>
>  Documentation/git-rev-parse.txt |   34 ++++++++++++++++++++++++++++++++--
>  builtin/rev-parse.c             |   17 ++++++++++++++++-
>  t/t1502-rev-parse-parseopt.sh   |   20 ++++++++++++++++++++
>  3 files changed, 68 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
> index 0d2cdcd..b8aabc9 100644
> --- a/Documentation/git-rev-parse.txt
> +++ b/Documentation/git-rev-parse.txt
> @@ -284,13 +284,13 @@ Input Format
>  
>  'git rev-parse --parseopt' input format is fully text based. It has two parts,
>  separated by a line that contains only `--`. The lines before the separator
> -(should be more than one) are used for the usage.
> +(should be one or more) are used for the usage.
>  The lines after the separator describe the options.
>  
>  Each line of options has this format:
>  
>  ------------
> -<opt_spec><flags>* SP+ help LF
> +<opt_spec><flags>*<arg_hint>? SP+ help LF
>  ------------
>  
>  `<opt_spec>`::
> @@ -313,6 +313,12 @@ Each line of options has this format:
>  
>  	* Use `!` to not make the corresponding negated long option available.
>  
> +`<arg_hint>`::
> +	`<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.

> @@ -333,6 +339,8 @@ h,help    show the help
>  
>  foo       some nifty option --foo
>  bar=      some cool option --bar with an argument
> +baz=arg   another cool option --baz with a named argument
> +qux?path  qux may take a path argument but has meaning by itself
>  
>    An option group Header
>  C?        option C with an optional argument"
> @@ -340,6 +348,28 @@ C?        option C with an optional argument"
>  eval "$(echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?)"
>  ------------
>  
> +
> +Usage text
> +~~~~~~~~~~
> +
> +When "$@" is "-h" or "--help" the above example would produce the following
> +usage text:

Sounds like a good idea to add this; all the above arguments inside
double quotes should be typeset `as-typed`, though.

> @@ -419,6 +420,20 @@ static int cmd_parseopt(int argc, const char **argv, const char *prefix)
>  		o->value = &parsed;
>  		o->flags = PARSE_OPT_NOARG;
>  		o->callback = &parseopt_dump;
> +
> +		/* Possible argument name hint */
> +		end = s;
> +		while (s > sb.buf && strchr("*=?!", s[-1]) == NULL)
> +			--s;
> +		if (s != sb.buf && s != end) {
> +			char *a;
> +			o->argh = a = xmemdupz(s, end - s);
> +			while (a = strchr(a, '_'))
> +				*a = ' ';

... and without the "underscore" munging, we do not have to allocate
a new piece of memory, either.

  reply	other threads:[~2014-03-20 18:38 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-03 10:32 [PATCH] rev-parse --parseopt: option argument name hints Ilya Bobyr
2014-03-04 19:22 ` Junio C Hamano
2014-03-10  5:47   ` Ilya Bobyr
2014-03-10  5:55     ` [PATCH v2] " Ilya Bobyr
2014-03-10 19:55     ` [PATCH] " Junio C Hamano
2014-03-11 19:10       ` Junio C Hamano
2014-03-12  7:26         ` Ilya Bobyr
2014-03-12 16:59           ` Junio C Hamano
2014-03-19  9:02             ` Ilya Bobyr
2014-03-19 18:46               ` Junio C Hamano
2014-03-20  8:38                 ` Ilya Bobyr
2014-03-20  8:44                   ` [PATCH v3] " Ilya Bobyr
2014-03-20 18:38                     ` Junio C Hamano [this message]
2014-03-20 23:19                       ` Ilya Bobyr
2014-03-21  7:55                         ` Ilya Bobyr
2014-03-21 17:04                         ` Junio C Hamano
2014-03-22  9:47                           ` [PATCH v4] " Ilya Bobyr
2014-03-24 17:52                             ` [PATCH 0/3] Parse-options: spell multi-word placeholders with dashes Junio C Hamano
2014-03-24 17:52                               ` [PATCH 1/3] parse-options: multi-word argh should use dash to separate words Junio C Hamano
2014-03-24 17:52                               ` [PATCH 2/3] update-index: teach --cacheinfo a new syntax "mode,sha1,path" Junio C Hamano
2014-03-24 17:52                               ` [PATCH 3/3] parse-options: make sure argh string does not have SP or _ Junio C Hamano
2014-03-20 20:18                     ` [PATCH v3] rev-parse --parseopt: option argument name hints Eric Sunshine
2014-03-21  3:38                       ` Ilya Bobyr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqpplgyaud.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=ilya.bobyr@gmail.com \
    --cc=jrnieder@gmail.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.