Re: [bug-gnulib] argp: output formatting, and argp_child interface.

[Paul Knowles]

>Bruno Haible replied on 2006-01-09:
>Paul Knowles wrote on 2005-12-15:
>> ******* Problem #1
>> struct argp{
>>   ...
>>   /* A vector of argp_children structures, terminated by a member with a 0
>>      argp field, pointing to child argps should be parsed with this one.  Any
>>      conflicts are resolved in favor of this argp, or early argps in the
>>      CHILDREN list.  This field is useful if you use libraries that supply
>>      their own argp structure, which you want to use in conjunction with your
>>      own.  */
>>   __const struct argp_child *children;
>>   ...
>> }
>> 
>> In my opinion, much better would be 
>>     struct argp_child **children;
>> for the reason that multiparser structures can then have an easy to
>> use, scalable, interface.  By adding a function to add children, much
>> of the complexity of the multiparser setup will go away.
>
>Sorry, I don't understand. The argp facility is meant for a set of options
>known when the program starts. (Otherwise how do you manage to write a
>manual page for the program?) Do you mean to add options dynamically?

Yes, I will agree that the ``options are known when the
program starts'', but, why should the options that apply to
the functions contained in file foo.c not be contained in
that file?  For a small project with a few files, putting
all the help and options parsing in one central file is fine.
My project has some 6 different frequency estimators, each
with different configuration parameters, and it is a royal
pain to have to touch two different files just to add one
modification to one suboption of one estimator (the 34
different windowing functions are just so much fun too!).
Since the group of people using the code will also want to
be able to add estimators, I need to make the interface very
simple: they add one _one_ pointer to one array in main(), and
all the other work for options and so on must happen
transparently.  ``struct argp_child *'' makes my job harder
in that respect.

So, the change to a struct argp_child ** would clean up the
programming interface for adding suboptions to the options list.
Options can be easily kept with the code they control, and a
simple list builder can initializer the parser array before
argument parsing.  

This is not just my problem: libbow has faced the same thing
(http://www.cs.cmu.edu/~mccallum/bow/) and solved it via:

bow>> #define MAX_NUM_CHILDREN 100
bow>> struct argp_child bow_argp_children[MAX_NUM_CHILDREN] =
bow>> {
bow>>   {
bow>>     &bow_argp,                  /* the argp structure */
bow>>     0,                          /* flags for child */
bow>>     "Libbow options",           /* optional header */
bow>>     999                         /* group (general lib flags at end of 
help)*/
bow>>   },
bow>>   {0}
bow>> };
bow>> 
bow>> /* The number of children already initialized in the const assignment 
above. */
bow>> static int bow_argp_children_length = 1;
bow>> 
bow>> /* Add the options in CHILD to the list of command-line options. */
bow>> void
bow>> bow_argp_add_child (struct argp_child *child)
bow>> {
bow>>   assert (bow_argp_children_length+1 < MAX_NUM_CHILDREN);
bow>>   memcpy (bow_argp_children + bow_argp_children_length,
bow>>           child,
bow>>           sizeof (struct argp_child));
bow>>   bow_argp_children_length++;
bow>> #if 1
bow>>   memset (bow_argp_children + bow_argp_children_length,
bow>>           0, sizeof (struct argp_child));
bow>> #endif
bow>> }

It works (provided the uses have no more than 98 children to
add), but for me, the adding of arbitrary number of parser
children is code that really belongs to the argp API, and
shouldn't be kludged together by each argp user who faces
this problem.  It is also ugly that the solution requires
_two_ copies of each child struct, the initializer, and the
working copy in the array.


>> ******* Problem #2
>> Word wrapping should look at the COLUMNS environment variable to
>> determine word wrap unless rmargin=N was explicitly set by the user in 
>> ARGP_HELP_FMT.  It is silly that help text gets garbled and squashed
>> up into 79 columns on my 110 column xterms and that the resizing is
>> not automagic.
>
>I agree. But you can get the desired behaviour yourself: Put the value
>of getenv("COLUMNS") into ARGP_HELP_FMT.

I understand that, and that's what I will probably do, but I
think you will agree that passing something to the
environment, so that another part of the _same_ program can
read it out of the environment is ugly, and I've always been
well served by the hyphothesis ugly code == fragily easily
broken buggy code.

>> *******  Problem 3;
>>  I believe I have also stumbled on an output formatting problem, but
>> the code to duplicate a test case of this is not yet ready.
>Can you provide the test case, please?

If I can find the time to make a small test case that
reproduces the problem, i will.  Teaching semester is on at
the moment however,

thanks for your comments,

Paul Knowles.                   phone: 41 26 300 90 64
email: address@hidden      Fax: 41 26 300 97 47
finger me at pexppc33.unifr.ch for more contact information