By combining Clon’s ability to use a virtual command-line, different
synopsis and multiple contexts, you can achieve very neat (read: totally
useless) things. For instance, you could write an application that takes
an option providing command-line arguments for an external program to be
forked. Some revision control systems do that for controlling external
diff programs for instance, so no big deal. The big deal is that
you can completely control the validity of the external program’s
command-line, before it is forked, from your original one.
Here is another idea, again related to revision control systems. Some of them feature a command-line syntax like the following:
prog [global options] command [command-specific options]
You can achieve this with Clon quite easily. In fact, the
demonstration program called advanced in the distribution shows
you how to do it. First, define a synopsis which only handles the global
options, and provide a postfix of "command [command-specific
option]" or something like that. This will authorize a command-line
remainder which will start with the command name.
Now, for every command in your program, define a specific synopsis with only the command-specific options. Get the remainder of the original command-line (see Command-Line Remainder) and figure out which command was used. Depending on it, create a new context with the appropriate synopsis and the original command-line’s remainder as the new, virtual, command-line. You’re done: retrieve global options from the first context, and command-specific ones from the second one.
What’s even cooler is that you can display the command-specific options
on demand quite easily as well (like what git does when you call
it like this: git commit --help for instance): calling the
help function on the original context gives you the global
options’s help string while calling it on the command-specific one will
display the command-specific usage.
One thing to remember here is that every context/synopsis duet you
create gets its own set of built-in Clon options. As a consequence,
there is currently no simple way to have a single set of built-in
options apply to the whole application, for instance, to both a global
and a command-specific context. Let me make this clearer: if your
end-user calls prog --clon-theme=foo command -h, then the theme
option will have no effect because it would only affect the global help
option. In order to actually use the expected theme, your end-user would
need to use prog command --clon-theme=foo -h. Depending on which
cerebral emisphere (s)he prefers to use, this may seem logical or not.
Finally, note that you can use the virtual command-line / specific synopsis technique recursively to manage complicated command-line syntax, for instance alternating options and non-options parts several times.
In the future, Clon may provide better ways to achieve this kind of
things (a notion of “sub-context” may be in order).