bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: Bruno Haible <bruno@clisp.org>
To: Akim Demaille <akim.demaille@gmail.com>
Cc: Paul Eggert <eggert@cs.ucla.edu>, bug-gnulib@gnu.org
Subject: Re: argmatch: accept perfect matches in documented arglists
Date: Thu, 20 Jun 2019 15:06:26 +0200	[thread overview]
Message-ID: <11405045.c7khPThjkt@omega> (raw)
In-Reply-To: <A9E9D0BD-5395-41D5-AA19-70DEDFCBC201@gmail.com>

Hi Akim,

Sorry for the delay.

> Here is my proposal.

It looks really good now. My comments below are only nitpicking.

I like the addition of documentation. It makes the module a lot easier to use.

> +2019-05-23  Akim Demaille  <akim@lrde.epita.fr>
> +
> +	argmatch: add support to generate the usage message.
> +	* lib/argmatch.c: Move some #includes and gettext support to...
> +	* lib/argmatch.h: here.
> +	(ARGMATCH_DEFINE_GROUP): New macro.
> +	* tests/test-argmatch.c (argmatch_backup_docs, argmatch_backup_args)
> +	(argmatch_backup_group): New.
> +	(CHECK): New.
> +	(main): Check argmatch_backup_value, argmatch_backup_xvalue,
> +	argmatch_backup_argument and argmatch_backup_usage.
> +	* doc/argmatch.texi (Recognizing Option Arguments): New.

The ChangeLog entry should mention that you modify doc/gnulib.texi.

> +@example
> +const argmatch_backup_group_type argmatch_backup_group =
> +@{
> +  N_("\
> +The backup suffix is '~', unless set with --suffix or SIMPLE_BACKUP_SUFFIX.\n\
> +The version control method may be selected via the --backup option or through\n\
> +the VERSION_CONTROL environment variable.  Here are the values:\n"),
> +  NULL,
> +  argmatch_backup_docs,
> +  argmatch_backup_args
> +@};
> +@end example

Why does not args element come last and the doc strings come first?
- It'd be more natural for a programmer to put the args element first.
- It at some point in the future, you need to add more doc strings,
  it would be easy to add them in a backward-compatible way at the end
  of the string (since a struct initializer implicitly initializes
  trailing members with NULL or 0 values).

> +ptrdiff_t i = argmatch_backup_value ("--backup", "none");
> +// argmatch_backup_group.args[i].arg is "none", so its value
> +// is argmatch_backup_group.args[i].val.
> +// Return -1 on invalid argument, and -2 on ambiguity.
> +
> +enum backup_type val = *argmatch_backup_xvalue ("--backup", "none");
> +// Returns a pointer to the value, and exit on errors.
> +// So argmatch_backup_group.args[i].val == val.

The naming of the functions is a bit odd. argmatch_backup_xvalue
returns a value, and argmatch_backup_value return not a value but
a choice (an index or -1 or -2). How about renaming these functions:
  argmatch_backup_value -> argmatch_backup_choice
  argmatch_backup_xvalue -> argmatch_backup_value

> +  /* If nonnegative, the indice I of ARG in ARGS, i.e,                  \

"the indice" is not valid English.
https://www.merriam-webster.com/dictionary/indice
The singular of 'indices' is 'index'.

> +  void                                                                  \
> +  argmatch_##Name##_usage (FILE *out)                                   \
> +  {                                                                     \
> +    ...
> +    if (g->doc_pre)                                                     \
> +      fprintf (out, "%s\n", _(g->doc_pre));                             \
> +    int doc_col = argmatch_##Name##_doc_col ();                         \

Local variable declarations after statements in the same block are a C99
feature. Can you change it to use C99 syntax? Or, if you can't, add 'c99'
to the module dependencies.

Bruno



  parent reply	other threads:[~2019-06-20 13:19 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-18 20:58 argmatch: accept perfect matches in documented arglists Akim Demaille
2019-04-27 12:33 ` Bruno Haible
2019-04-27 16:36   ` Akim Demaille
2019-04-27 17:56     ` Bruno Haible
2019-05-02 10:55       ` Akim Demaille
2019-05-05 14:28         ` Bruno Haible
2019-05-19 10:10           ` Akim Demaille
2019-05-19 11:05             ` Bruno Haible
2019-05-19 11:50               ` Akim Demaille
2019-05-19 12:01                 ` Bruno Haible
2019-05-19 12:14                   ` Akim Demaille
2019-05-19 15:02                     ` Akim Demaille
2019-05-19 16:13                       ` Bruno Haible
2019-05-19 16:37                         ` Paul Eggert
2019-05-19 16:52                           ` Akim Demaille
2019-05-21  7:16                         ` Akim Demaille
2019-05-21 16:18                           ` Paul Eggert
2019-05-22  5:18                             ` Akim Demaille
2019-05-22  8:59                               ` Bruno Haible
2019-05-25  7:36                                 ` Akim Demaille
2019-06-04 16:03                                   ` Akim Demaille
2019-06-20  5:13                                     ` Akim Demaille
2019-06-20 13:06                                   ` Bruno Haible [this message]
2019-06-21 16:35                                     ` Akim Demaille
2019-06-21 21:21                                       ` Bruno Haible
2019-06-22  6:46                                         ` Akim Demaille
2019-06-22  7:57                                           ` Bruno Haible
2019-06-25  6:21                                             ` Akim Demaille

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

  List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib

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

  git send-email \
    --in-reply-to=11405045.c7khPThjkt@omega \
    --to=bruno@clisp.org \
    --cc=akim.demaille@gmail.com \
    --cc=bug-gnulib@gnu.org \
    --cc=eggert@cs.ucla.edu \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).