[nmh-workers] Refactoring smatch

Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[nmh-workers] Refactoring smatch

Ken Hornstein-2
I have decided to start working on my to-do list for nmh again, and at
the top of that list was "refactor smatch()".  Specifically, I would
like to have smatch do the following things:

- Automatically handle switch arguments.  There are a lot of these cases
  in the code:

    if (!(cp = *argp++) || *cp == '-')
        die("missing argument to %s", argp[-2]);

  And I have to ask myself ... why isn't smatch() just handling that??
  There's not really a reason it shouldn't do a little bit of that, since
  that code is duplicated over and over.

  It seems the existing convention is that if there is a space in the
  switch name it takes an argument.  E.g.:

    X("src +folder", 0, SRCSW) \
    X("file file", 0, FILESW) \
    X("rmmproc program", 0, RPROCSW) \
    X("normmproc", 0, NRPRCSW) \

  The switch matching code already knows that a space is the end of the
  argument name, so it seems reasonable to just go with that as an indicator
  that a switch takes an argument and if it does then process the argument
  and return back.

- Handle subcommands.  Right now there is a lot of work when you add a new
  switch to post(8) because switches to post are passed down from send(1)
  and whatnow(1) and whom(1) (there are probably other commands that do
  this a lot as well).  So being able to pass in an additional smatch array
  and have it build up an argument vector would be a huge win.  How the
  exact API would work there is a bit of an open question, 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);

  Or, you know, something like that.

Thoughts?

--Ken

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: 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.

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers