From: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>
To: Stephen Boyd <bebarino@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] parse-options: make OPT_NUMBER's argh explicit
Date: Wed, 03 Jun 2009 22:22:59 +0200 [thread overview]
Message-ID: <4A26DBA3.90604@lsrfire.ath.cx> (raw)
In-Reply-To: <780e0a6b0906031235q1438b76cyba1172556c94d1d0@mail.gmail.com>
Stephen Boyd schrieb:
> On Wed, Jun 3, 2009 at 3:18 AM, René Scharfe<rene.scharfe@lsrfire.ath.cx> wrote:
>> By the way, can the switch be replaced by a simple check for
>> PARSE_OPT_NOARG now?
>>
>
> This looks possible. I think just set PARSE_OPT_NOARG as the flag of
> the appropriate OPT_* macros. I'll have to grep the tree for custom
> uses of OPTION_* though.
Yes, it's only worthwhile if there aren't too many special cases that
require explicit setting of PARSE_OPT_NOARG.
>
> Should that be all squashed together? Or maybe that could be a follow up patch?
Your existing patch looks fine as is, I'd keep additional changes
separate.
Hmm, and how about the following in between them?
parse-options.c | 16 +++-------------
1 files changed, 3 insertions(+), 13 deletions(-)
diff --git a/parse-options.c b/parse-options.c
index b85cab2..dda36b1 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -440,7 +440,7 @@ int parse_options(int argc, const char **argv, const char *prefix,
static int usage_argh(const struct option *opts)
{
const char *s;
- int literal = opts->flags & PARSE_OPT_LITERAL_ARGHELP;
+ int literal = (opts->flags & PARSE_OPT_LITERAL_ARGHELP) || !opt->argh;
if (opts->flags & PARSE_OPT_OPTARG)
if (opts->long_name)
s = literal ? "[=%s]" : "[=<%s>]";
@@ -448,7 +448,7 @@ static int usage_argh(const struct option *opts)
s = literal ? "[%s]" : "[<%s>]";
else
s = literal ? " %s" : " <%s>";
- return fprintf(stderr, s, opts->argh);
+ return fprintf(stderr, s, opt->argh ? opt->argh : "...");
}
#define USAGE_OPTS_WIDTH 24
@@ -519,17 +519,7 @@ int usage_with_options_internal(const char * const *usagestr,
case OPTION_FILENAME:
/* FALLTHROUGH */
case OPTION_STRING:
- if (opts->argh)
- pos += usage_argh(opts);
- else {
- if (opts->flags & PARSE_OPT_OPTARG)
- if (opts->long_name)
- pos += fprintf(stderr, "[=...]");
- else
- pos += fprintf(stderr, "[...]");
- else
- pos += fprintf(stderr, " ...");
- }
+ pos += usage_argh(opts);
break;
default: /* OPTION_{BIT,BOOLEAN,NUMBER,SET_INT,SET_PTR} */
break;
next prev parent reply other threads:[~2009-06-03 20:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-03 7:49 [PATCH] parse-options: make OPT_NUMBER's argh explicit Stephen Boyd
2009-06-03 10:18 ` René Scharfe
2009-06-03 19:35 ` Stephen Boyd
2009-06-03 20:22 ` René Scharfe [this message]
2009-06-04 23:43 ` [PATCHv2 1/2] parse-options: make OPT_INTEGER's " Stephen Boyd
2009-06-04 23:43 ` [PATCHv2 2/2] parse-options: simplify usage argh handling Stephen Boyd
2009-06-06 10:30 ` René Scharfe
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=4A26DBA3.90604@lsrfire.ath.cx \
--to=rene.scharfe@lsrfire.ath.cx \
--cc=bebarino@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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.