[help-gengetopt] Another Wish

[T]

[instigated by your welcome attitude]

On Fri, 13 Oct 2006 10:36:11 +0200, Lorenzo Bettini wrote:

>> So I wish that gengetopt can have another option to show help for parameters
>> in details ...
> 
> ...
> This would require to add also another field in the option in the .ggo 
> file (for instance details="<very long help description>")

hold the thought, don't finalize the UI yet please, because I think the
current approach is not the best way to allow user to specify detail helps
like this:

---------------------
    -k --stop which
        Kill currently running agent processes. The following values are
        valid for "which":

        all      Kill all agent processes and quit keychain immediately.
                 Prior to keychain-2.5.0, this was the behavior of the bare
                 "--stop" option.

        others   Kill agent processes other than the one keychain is
                 providing. Prior to keychain-2.5.0, keychain would do this
                 automatically. The new behavior requires that you specify
                 it explicitly if you want it.

        mine     Kill keychain's agent processes, leaving other agents
                 alone.
---------------------

It sure can, but just not that easy. To address the problem, allow me to
share my envision of future gengetopt first.

IMHO, there is still one road block for gengetopt to be widely
adopted. Currently the options are presented to users like a snapshot --
the dynamic is lost. I.e., the order the options are passed are lost. 

For example, the option for the 'sort' program, allows user to sort this
fields numerically, but that field alphabetically. It all depends on the
order of -k and -n passed to the program. What other programs care about the
order of the options? Lots, ffmpeg, transcode, xmlstarlet, to name a few.

Further, there are programs that one option is a synonym for a lot of
options. E.g., -a for 'cp' and rsync, 'stty sane', 'ffmpeg -target', &
'transcode -export_profile'...

I'm thinking, the only way for users to handle complicated requirements like
above, is to allow them to specify their own add-on code during options
processing.

This again, requires users to specify multi-line nicely formatted text 
in gengetopt configuration file. IMHO, the best way to handle this, is 
to use a brand new format -- use xml. 

I'm proposing, something like this:

------------------------------------------------
<options package="sample1" version="2.0" 
        purpose="this is just a test program for gengetopt" >
 <item type="option" long="str-opt" short="s" 
  desc="A string option, for a filename" 
  argtype="string" typestr="filename" 
  required="optional" >
   <details>
very long help description

more lines

here
   </details>
 </item>
 <item type="option" long="int-opt" short="i" desc="A int option" argtype="int" 
required="required" />
 <item type="option" long="my-opt" short="m" desc="Another integer option, this 
time the description of the option should be quite long to require wrapping... 
possibly more than one wrapping :-) especially if I\nrequire a line break" 
argtype="int" required="optional" />

<item type="section" name="more involved options" desc="the following 
options\nare more complex" />
 <item type="text" text="" />
 <item type="option" long="test-opt" short="t" desc="A string option" 
argtype="string" required="optional" argoptional="1" default="abc" />
 <item type="option" long="flag1" short="-" desc="A normal flag option" 
required="optional" />
 <item type="flag" long="flag2" short="-" desc="A toggle flag option" 
onoff="off" />

<item type="section" name="last option section" />
 <item type="option" long="long-opt" short="-" desc="A long option" 
argtype="long" required="required" argoptional="1" />

 <item type="text" text="\nAn ending text." />
</options>
------------------------------------------------

As you can see, it almost identical to the .ggo format, just everything is
wrapped in xml.

The idea sounds horrific at first, but it will actually simplify the
gengetopt configuration file parsing. It will befit the users too, because
their configuration file will looks nicer, no longer having those
extremely-long lines, are more easy for version control.

What do you think? You can freeze the .ggo format syntax & parsing and
introduce the xml as an alternative configuration file format for new
features, then deprecate .ggo format later.

-- 
Tong (remove underscore(s) to reply)
  http://xpt.sourceforge.net/