On 06/05/2010 8:56 AM, Jeff Johnson wrote:
(aside)
Anything you want to see in POPT 2.0? I'm collecting features ...
Since you're collecting features... =)
One thing I'd like is to extend the help/usage capability just a little.
So I'd like to be able to have more descriptive usage parameters (eg. to
cover left-over arguments). I addition it'd be nice to have a little
description/summary of what the program to do. I realize you can do
this with a custom help function. But it'd be nice if these were
standard elements.
Other niceties might be:
- a way to indicate parameters enabled by default (eg. having a '*'
next to them in the help)
- An additional structure that could provide detailed help on
argDescription elements. For example, rpm has an option:
--queryformat=QUERYFORMAT use the following query format
It'd be nice if there were a section of help that could describe
what QUERYFORMAT could be. So obviously it's not going to be a full man
page, but perhaps it could just show supported % format options or
something like that.
I use something like this in my code, but I have specific keys like
"[replaceme]" that I convert. And I put just the acceptable keys in the
help cause I just need a quick reminder of what they are. But it
clutters the option help a little. I'd be fine with specifying
"FORMATSTRING" in the option help. Then have perhaps an arg help down
below that shows what values FORMATSTRING understands.
I'm not sure exactly how you could support these without breaking
compatability with existing apps. Perhaps a new datatype something like:
enum poptOptionType {
POPT_OPTION,
POPT_ARG,
POPT_USAGE,
};
union poptDetailedOption {
poptOptionType optType;
struct poptShortOption;
struct poptArgHelp;
struct poptUsageHelp;
}
struct poptShortOption { /* same as poptOption but with a type field */
poptOptionType optType;
const char * longName;
char shortName;
int argInfo;
void * arg;
int val;
const char * descrip;
const char * argDescrip;
};
I'm not sure this would give the desired effect.. but the thought would
be that it'd turn your options table to something like this:
poptDetailedOption optionsTable[] = {
{ POPT_OPTION, "bps", 'b', POPT_ARG_INT, &speed, 0,
"signaling rate in bits-per-second", "BPS" },
{ POPT_ARG, "FORMATSTRING", "Possible formatting options are
[foo] [bar]" },
{ POPT_USAGE, "infile [outfile]" },
{ POPT_SUMMARY, "This program converts your data to
something...." },
I don't think the union will allow it to look exactly like that. In
fact it may not even be possible to initialize it that way(?) Maybe
we'd have to do something wonky with macros to make it look nice. But
you get the idea.
If you wanted to get really fancy the "POPT_USAGE" example I gave could
be separated into something like this:
{ POPT_EXTRAARG,
"infile",
1 /* required */,
"specify input filename",
"stdin" /* default value */
},
{ POPT_EXTRAARG,
"outfile",
0 /* optional */,
"file to output" /* description */
"stdout" /* default value */
}
This would allow the autohelp to generate "standard" extra arg displays
(eg. [] for optional parameters, etc.).
Admittedly this feature may be a bit questionable as many programs may
have rather complex "extra args". But I think a lot of programs fall
into this simple category as well.
Anyway, just a few thoughts...
______________________________________________________________________
POPT Library http://rpm5.org
Developer Communication List popt-devel@rpm5.org
