All of lore.kernel.org
 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
2007-10-14  9:18 ` 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
     [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
  -- 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 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.