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
next prev 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).