Re: [help-gengetopt] Gengetopt 2.21 enhancement suggestions

[Lorenzo Bettini]

J. David Bryan wrote:
> Greetings,

hi there

sorry for the delay of my answer but I had a busy week and I also need 
to move to Turin 
(http://tronprog.blogspot.com/2007/10/researcher-in-turin.html well it's 
a little bit off topic but I wanted to share this with you :-)

> I have been using gengetopt for a few months and have used it to generate 
> option processors for about ten programs.  From my use, I have three 
> suggestions for a future version:
>
>  1. Allow the automatic addition of the help and version options if the
>     user respecifies the short options (but not the long options).
>
>     Currently, if either the long or short option is respecified, the
>     built-in usage is suppressed.  For example, if the user specifies
>     his own "-h" ("--height") option, the built-in help option is lost,
>     and the user must provide it manually.  However, often we still want
>     to use "--help" for the help option and "--version" for the version
>     option (just without short options).  It would be nicer if gengetopt
>     provided these automatically.  Of course, if the user specified a
>     "--help" or "--version" (long) option explicitly, then gengetopt
>     should not provide its own.
>
>     The attached "gengetopt-2.21-enh-1.diff" suggests an implementation.

yes, you're right!

>  2. Provide a way to suppress the error message from "getopt_long" for an
>     invalid option.
>
>     The "--no-handle-error" option to gengetopt causes the parser to
>     return an error value to the calling program.  The manual says that
>     this is so "the program can print a help message."  However,
>     "getopt_long" always prints an error message before returning the
>     error indication.  This is because "opterr = 1" is set within the
>     parser and cannot be changed by the user.
>
>     It would be nice if the value (0 or 1) could be specified by the
>     user, so that the user program can handle the error completely if
>     desired.  Either "opterr" could be set automatically to 0 if the
>     "--no-handle-error" option to gengetopt was used, or "opterr" could
>     be set from a new cmdline_parser_params" item that the user would
>     set explicitly (with default to 1) and then pass to
>     "cmdline_parser_ext".
>
>     This is useful in cases where options are used that either do not
>     match C identifier syntax (e.g., "-?") or are unknown until run time
>     (e.g., "-<n>", where the values for <n> are determined by the
>     contents of a file specified on the command line).  The generated
>     parser can still be used to handle the help and version options (and
>     perhaps more), while the caller can handle the "unparseable" options
>     without spurious error messages appearing.
>
>     The attached "gengetopt-2.21-enh-2.diff" suggests an implementation.

OK, but, in case, how can someone understand if there's actually an 
error and print the corresponding error message?

by the way, the print_errors field should default to '1' to be backward 
compliant

>  3. Allow an option with a "values=" restriction to return a specified
>     argtype.
>
>     When "values=" is specified, the manual says that "The type is
>     considered string and must not be specified."  However, the option
>     value often is not a string and must be converted for use.  For
>     example, a "--rotate" option might limit values to 0, 90, 180, or
>     270 degrees.  The rotation value is an integer, but it will be
>     returned as a string, and the caller must do string comparisons or a
>     string-to-int conversion.
>
>     What would be more flexible would be to allow "argtype" to be
>     specified in addition to "values=".  So if we had:
>
>       option "rotate" r "Rotate clockwise" int values="0","90","180","270"
>
>     ...then the return value would be one of the four integers converted
>     from a string.  Specifying "string" as the "argtype" would return a
>     string value (as gengetopt does now).  Specifying "enum" would
>     generate an enumeration type (example: "enum rotate_type { rotate_0,
>     rotate_90, ... };") and return one of the enumeration values.  Note
>     that if the argtype defaulted to "string," the new behavior would be
>     backward-compatible.
>
>     This issue was previously discussed in:
>
>     http://lists.gnu.org/archive/html/help-gengetopt/2006-04/msg00007.html
>
>     ...in the context of returning enumeration values (only).

yes I remember that and should have worked on that already; do you think 
 using enum values would solve also the argtype issue?  I'm asking 
because adding enum values would be quite simple, while adding types to 
values would require some more time (it could be done anyway)

thanks for the patches!

as I said previously I'm still working on the re-engineering of the 
generated code (which now should be much more manageable and thus also 
adding new features would be easier), but I'm almost done, so I hope I 
could start working on new features soon.

look forward to hearing from you!

cheers
        Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DSI, Univ. di Firenze
ICQ# lbetto, 16080134     (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com  http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net