git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Kristian Høgsberg" <krh@redhat.com>
To: Jonas Fonseca <fonseca@diku.dk>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	gitster@pobox.com, git@vger.kernel.org
Subject: Re: [PATCH 1/4] Add a simple option parser for use by builtin-commit.c.
Date: Wed, 03 Oct 2007 17:53:58 -0400	[thread overview]
Message-ID: <1191448438.7134.8.camel@hinata.boston.redhat.com> (raw)
In-Reply-To: <20071003201129.GB25856@diku.dk>


On Wed, 2007-10-03 at 22:11 +0200, Jonas Fonseca wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote Mon, Oct 01, 2007:
> > On Mon, 1 Oct 2007, Kristian H?gsberg wrote:
> > > On Sun, 2007-09-30 at 15:11 +0200, Jonas Fonseca wrote:
> > > > > +
> > > > > +extern int parse_options(const char ***argv,
> > > > > +			 struct option *options, int count,
> > > > > +			 const char *usage_string);
> > > > 
> > > > I think the interface could be improved a bit. For example, it doesn't 
> > > > need to count argument since the last entry in the options array is 
> > > > OPTION_LAST and thus the size can be detected that way.
> > > 
> > > Hehe, yeah, that's how I did it first.  I don't have a strong preference 
> > > for terminator elements vs. ARRAY_SIZE(), but Junio prefers the 
> > > ARRAY_SIZE() approach, I guess.  At this point I'm just trying the get 
> > > the patches upstream...
> > 
> > FWIW I like the ARRAY_SIZE() approach better, too, since it is less error 
> > prone.
> 
> OK, I must have missed that comment. Good point.
> 
> Thanks for the comments both of you. It's great to have something to
> work from. However, I also fear it will also require that some extra
> flags or information is added to the option information to make it more
> generally usable. But I guess that is easier to discuss in the context
> of a patch.

I just sent an updated option parser patch that incorporates your
suggestions along with a patch that ports builtin-add.c to use it.  I
looked briefly into porting over a few other builtins, but you're right,
we need a couple of extra features for this to be really worthwile:

      * OPTION_SET_FLAG: sets the bit (we need to add a bit value that
        the option parser can or in)
      * OPTION_CLEAR_FLAG: clear the bit
      * OPTION_ADD: adds the value to the destination integer
      * OPTION_CALLBACK: calls the given function when the option is
        matched.  We'll need this for builtin-grep that has positional
        args such as --and etc.

Also, the option parser should probably verify that a string option
isn't passed more than once.  Bundling of single letter options would be
nice to add.  But the patch I just sent out should be a good start, and
it lets us move forward with builtin-commit.c.

cheers,
Kristian

      reply	other threads:[~2007-10-03 21:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-27  4:50 [PATCH 1/4] Add a simple option parser for use by builtin-commit.c Kristian Høgsberg
2007-09-27  4:50 ` [PATCH 2/4] This exports the update() function from builtin-add.c as Kristian Høgsberg
2007-09-27  4:50   ` [PATCH 3/4] Implement git commit as a builtin command Kristian Høgsberg
2007-09-27  4:50     ` [PATCH 4/4] Move launch_editor() and stripspace() to new file editor.c Kristian Høgsberg
2007-09-27  9:05   ` [PATCH 2/4] This exports the update() function from builtin-add.c as Junio C Hamano
2007-10-03 22:03     ` Kristian Høgsberg
2007-09-27 11:47   ` Johannes Schindelin
2007-09-27 19:50     ` Junio C Hamano
2007-09-30 13:11 ` [PATCH 1/4] Add a simple option parser for use by builtin-commit.c Jonas Fonseca
2007-10-01 10:14   ` Johannes Schindelin
2007-10-01 10:31     ` Jonas Fonseca
2007-10-01 11:39       ` Johannes Schindelin
2007-10-01 15:00     ` Jeff King
2007-10-01 16:26   ` Kristian Høgsberg
2007-10-01 18:13     ` Johannes Schindelin
2007-10-03 20:11       ` Jonas Fonseca
2007-10-03 21:53         ` Kristian Høgsberg [this message]

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=1191448438.7134.8.camel@hinata.boston.redhat.com \
    --to=krh@redhat.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=fonseca@diku.dk \
    --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).