Hi again,
I had a couple of ideas regarding options.
1. Many programs like to provide "alias" options. For example:
--quiet the same as --silent.
Typically, these are added to provide backwards compatibility, or
compatibility with another piece of software and the lack of support for
them in gengetopt might be problematic to people switching existing
software over to it.
I have two suggestions of ways that these could be implemented, but
neither of them are entirely elegant.
One solution might be to add a new .ggo file directive. For example, of
the form 'alias<long> <short> <aliased option> {desc="<description>"}'
and which also takes some parameters ("details", "typestr" and "hidden")
but inherits the values for others ("argtype", "values", "default",
"dependon", "required", "argoptional" and "multiple") from the option
that is being aliased. In terms of generated code, these options would
simply be another case label in the switch statement that falls through
to the option being aliased.
The major drawback to the above idea is that it would be hard to specify
*only* a short option that aliases another. One way round this would be
to introduce a way to specify that there is no long option (such as
giving an unquoted '-') that is only permitted in the alias directive.
Another option might be to add two new parameters to option directives
in the .ggo file. Something like, 'alias_short="<short>"' and
'alias_long="<long>"', both of which could be specified multiple times
for the same option. The downside to this is that there would be no way
to specify the alias option's "description" or, for example, to specify
any "details" or a different "typestr" for it.
2. Facility to make options config-file-only, or command-line-only.
Currently there is no way to limit the contexts in which options are
permitted. For example, a "--config-file=FILE" option would have no
place in a config file.
A suggested solution to this would be to add a parameter to option
directives in the .ggo file to allow the developer to specify the
contexts in which an option is permitted. For example,
'context="<context1>","<context2>",...' where the context values are,
basically, the names of the parsers that will accept the option.
Another thing to consider here is that programs sometimes have system
configuration files, and user configurations files. Some options may not
be appropriate for one or the other. These contexts would of course be
application-dependent.
All the best,