git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pierre Habouzit <madcoder@debian.org>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] Add a simple option parser.
Date: Sat, 13 Oct 2007 16:58:09 +0200	[thread overview]
Message-ID: <20071013145809.GG7110@artemis.corp> (raw)
In-Reply-To: <Pine.LNX.4.64.0710131519510.25221@racer.site>

[-- Attachment #1: Type: text/plain, Size: 4865 bytes --]

On Sat, Oct 13, 2007 at 02:39:10PM +0000, Johannes Schindelin wrote:
> Hi,
> 
> On Sat, 13 Oct 2007, Pierre Habouzit wrote:
> 
> > Aggregation of single switches is allowed:
> >   -rC0 is the same as -r -C 0 (supposing that -C wants an arg).
> 
> I'd be more interested in "-rC 0" working...  Is that supported, too?

  yes it is.

> > +static inline const char *get_arg(struct optparse_t *p)
> > +{
> > +	if (p->opt) {
> > +		const char *res = p->opt;
> > +		p->opt = NULL;
> > +		return res;
> > +	}
> > +	p->argc--;
> > +	return *++p->argv;
> > +}
> 
> This is only used once; I wonder if it is really that more readable having 
> this as a function in its own right.

  it's used twice, and it makes the code more readable I believe.

> > +static inline const char *skippfx(const char *str, const char *prefix)
> 
> Personally, I do not like abbreviations like that.  They do not save that 
> much screen estate (skip_prefix is only 4 characters longer, but much more 
> readable).  Same goes for "cnt" later.

  Ack I'll fix that.

> > +static int parse_long_opt(struct optparse_t *p, const char *arg,
> > +                          struct option *options, int count)
> > +{
> > +	int i;
> > +
> > +	for (i = 0; i < count; i++) {
> > +		const char *rest;
> > +		int flags = 0;
> > +		
> > +		if (!options[i].long_name)
> > +			continue;
> > +
> > +		rest = skippfx(arg, options[i].long_name);
> > +		if (!rest && !strncmp(arg, "no-", 3)) {
> > +			rest = skippfx(arg + 3, options[i].long_name);
> > +			flags |= OPT_SHORT;
> > +		}
> 
> Would this not be more intuitive as
> 
> 		if (!prefixcmp(arg, "no-")) {
> 			arg += 3;
> 			flags |= OPT_UNSET;
> 		}
> 		rest = skip_prefix(arg, options[i].long_name);

  Yes, that can be done indeed, but the point is, we have sometimes
option whose long-name is "no-foo" (because it's what makes sense) but I
can rework that.

> Hm?  (Note that I say UNSET, not SHORT... ;-)

  fsck, good catch.

> > +		if (!rest)
> > +			continue;
> > +		if (*rest) {
> > +			if (*rest != '=')
> > +				continue;
> 
> Is this really no error?  For example, "git log 
> --decorate-walls-and-roofs" would not fail...

  it would be an error, it will yield a "option not found".

> > +int parse_options(int argc, const char **argv,
> > +                  struct option *options, int count,
> > +				  const char * const usagestr[], int flags)
> 
> Please indent by the same amount.

  oops, stupid space vs. tab thing.

> > +		if (arg[1] != '-') {
> > +			optp.opt = arg + 1;
> > +			do {
> > +				if (*optp.opt == 'h')
> > +					make_usage(usagestr, options, count);
> 
> How about calling this "usage_with_options()"?  With that name I expected 
> make_usage() to return a strbuf.

  will do.

> > +		if (!arg[2]) { /* "--" */
> > +			if (!(flags & OPT_COPY_DASHDASH))
> > +				optp.argc--, optp.argv++;
> 
> I would prefer this as 
> 
> 			if (!(flags & OPT_COPY_DASHDASH)) {
> 				optp.argc--;
> 				optp.argv++;
> 			}
> 
> While I'm at it: could you use "args" instead of "optp"?  It is misleading 
> both in that it not only contains options (but other arguments, too) as in 
> that it is not a pointer (the trailing "p" is used as an indicator of that 
> very often, including git's source code).

  okay.

> In the same vein, OPT_COPY_DASHDASH should be named 
> PARSE_OPT_KEEP_DASHDASH.

  okay.

> 
> > +		if (opts->short_name) {
> > +			strbuf_addf(&sb, "-%c", opts->short_name);
> > +		}
> > +		if (opts->long_name) {
> > +			strbuf_addf(&sb, opts->short_name ? ", --%s" : "--%s",
> > +						opts->long_name);
> > +		}
> 
> Please lose the curly brackets.
> 
> > +		if (sb.len - pos <= USAGE_OPTS_WIDTH) {
> > +			int pad = USAGE_OPTS_WIDTH - (sb.len - pos) + USAGE_GAP;
> > +			strbuf_addf(&sb, "%*s%s\n", pad, "", opts->help);
> > +		} else {
> > +			strbuf_addf(&sb, "\n%*s%s\n", USAGE_OPTS_WIDTH + USAGE_GAP, "",
> > +						opts->help);
> > +		}
> 
> Same here.  (And I'd also make sure that the lines are not that long.)

  okay.

> 
> > diff --git a/parse-options.h b/parse-options.h
> > new file mode 100644
> > index 0000000..4b33d17
> > --- /dev/null
> > +++ b/parse-options.h
> > @@ -0,0 +1,37 @@
> > +#ifndef PARSE_OPTIONS_H
> > +#define PARSE_OPTIONS_H
> > +
> > +enum option_type {
> > +	OPTION_BOOLEAN,
> 
> I know that I proposed "BOOLEAN", but actually, you use it more like an 
> "INCREMENTAL", right?

  yes, I don't like _BOOLEAN either, I would have prefered _FLAG or sth
like that. INCREMENTAL is just too long.

> Other than that: I like it very much.

:P

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2007-10-13 14:58 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-13 13:29 [RFC] CLI option parsing and usage generation for porcelains Pierre Habouzit
2007-10-13 14:53 ` Wincent Colaiuta
     [not found] ` <1192282153-26684-2-git-send-email-madcoder@debian.org>
2007-10-13 14:39   ` [PATCH] Add a simple option parser Johannes Schindelin
2007-10-13 14:58     ` Pierre Habouzit [this message]
     [not found]   ` <1192282153-26684-3-git-send-email-madcoder@debian.org>
2007-10-13 14:47     ` [PATCH] Port builtin-add.c to use the new " Johannes Schindelin
2007-10-13 15:03       ` Pierre Habouzit
2007-10-13 19:22         ` Alex Riesen
2007-10-13 20:27           ` Pierre Habouzit
     [not found]     ` <1192282153-26684-4-git-send-email-madcoder@debian.org>
     [not found]       ` <1192282153-26684-5-git-send-email-madcoder@debian.org>
     [not found]         ` <1192282153-26684-6-git-send-email-madcoder@debian.org>
     [not found]           ` <1192282153-26684-7-git-send-email-madcoder@debian.org>
     [not found]             ` <1192282153-26684-8-git-send-email-madcoder@debian.org>
     [not found]               ` <1192282153-26684-9-git-send-email-madcoder@debian.org>
     [not found]                 ` <1192282153-26684-10-git-send-email-madcoder@debian.org>
2007-10-14 14:01                   ` [PATCH] Simplify usage string printing Jonas Fonseca
2007-10-14 16:26                     ` Pierre Habouzit
2007-10-13 19:16   ` [PATCH] Add a simple option parser Alex Riesen
2007-10-13 20:54     ` Pierre Habouzit
2007-10-13 22:14       ` Alex Riesen
2007-10-14  7:02         ` Pierre Habouzit
2007-10-14 14:10   ` [PATCH] Update manpages to reflect new short and long option aliases Jonas Fonseca
2007-10-14 16:26     ` Pierre Habouzit
2007-10-14  9:18 ` [RFC] CLI option parsing and usage generation for porcelains Eric Wong
2007-10-14  9:57   ` Pierre Habouzit
2007-10-14 16:54     ` [PATCH] parse-options: Allow abbreviated options when unambiguous Johannes Schindelin
2007-10-14 18:02       ` Johannes Schindelin
2007-10-14 18:08         ` Pierre Habouzit
2007-10-14 21:01           ` Eric Wong
2007-10-14 22:12             ` Johannes Schindelin
2007-10-14 22:49               ` Eric Wong
2007-10-14 22:59                 ` git-svn and submodules, was " Johannes Schindelin
2007-10-15  7:07                   ` git-svn and submodules Benoit SIGOURE
2007-10-15 10:00                     ` Andreas Ericsson
2007-10-15 10:51                       ` Benoit SIGOURE
2007-10-15 10:14                     ` David Kastrup
2007-10-15 10:53                       ` Benoit SIGOURE
2007-10-15 16:27                         ` Andreas Ericsson
2007-10-15 14:45                     ` Karl Hasselström
2007-10-15 15:14                       ` .gitignore and svn:ignore [WAS: git-svn and submodules] Chris Shoemaker
2007-10-16  7:58                         ` Eric Wong
2007-10-16  9:43                           ` Karl Hasselström
2007-10-16 13:05                           ` Chris Shoemaker
2007-10-15 15:53                     ` git-svn and submodules Linus Torvalds
2007-10-15 16:17                       ` Performance issue with excludes (was: Re: git-svn and submodules) Benoit SIGOURE
2007-10-15 16:34                         ` Linus Torvalds
2007-10-15 16:51                           ` Benoit SIGOURE
2007-10-15 17:10                             ` Linus Torvalds
2007-10-15 17:38                               ` Benoit SIGOURE
  -- strict thread matches above, loose matches on Subject: below --
2007-10-03 21:45 [PATCH] Add a simple option parser Kristian Høgsberg
2007-10-03 23:11 ` Pierre Habouzit
2007-10-04 14:57   ` Kristian Høgsberg
2007-10-04 15:15     ` Pierre Habouzit
2007-10-04 16:31       ` Pierre Habouzit
2007-10-04 16:39         ` Johannes Schindelin
2007-10-05 10:08 ` Pierre Habouzit
2007-10-05 14:21 ` Pierre Habouzit

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=20071013145809.GG7110@artemis.corp \
    --to=madcoder@debian.org \
    --cc=Johannes.Schindelin@gmx.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).