Re: [nmh-workers] Refactoring smatch

[Ralph Corderoy]

Hi Ken,

I haven't looked at the code so this is based on recollection and your
email.

> because I could also imagine wanting to handle the case where several
> programs handled the same set of arguments.  So maybe that would be
> something like ...
>
>     int smatch(const char **, const struct swit *, ...);
>
> Where the additional arguments might be something like:
>
>     enum { SMATCH_ARGV, SMATCH_ADDITIONAL };
>
> and you'd do:
>
>     smatch(&argp, switches, SMATCH_ARGV, post_switches, post_argv);

I'd tend towards using X-macros in a #define of an option set, e.g. a
standard one that includes -help and -version.  These can be visible
through a #include and interpolated into a program-specific set that
overall makes up what directs smatch2().  A program like post can make
visible a macro with a series of X-macros that are its options its
intends higher programs like send to use.

The X-macro can map onto what's required at the time.  The overall list
of options in send would then be the standard ones, send's ones, and
post's ones, and by default presented with that grouping and order,
e.g. in -help output.  That seems to be a feature.

-- 
Cheers, Ralph.