Re: [Groff] Re: getopt() as gtroff macro ?

[Keith Marshall]

On Thursday 23 September 2004 12:20 pm, Werner LEMBERG wrote:
> > >> I think this is important and, while I admire what Keith has
> > >> done, I wonder if there's any way to get a getopt built into
> > >> gtroff?
> > >
> > > Nice idea.  What exactly do you have in mind?  Can you make syntax
> > > suggestions?
> >
> > I agree, this would be a nice feature to have.  Perhaps something
> > along the lines of the shell's built-in 'getopts' command?
> >
> > The main problem I foresee is, how do you implement the call backs
> > needed, to allow getopt's caller to handle the optional arguments as
> > they are parsed?  This could end up being no simpler than the
> > technique I suggested earlier, but it would be great if we can
> > identify a viable solution.
>
> What about the following (inspired by Python's getopt module):
>
>   .getopt <prefix> <options> <long options>
>
> Example:
>
>   .de foo
>   .  getopt "foox" "ac:" "--all --check="
>   .  ...
>   ..

Would the .getopt request not need to also include the arguments of the 
invoking macro?  Thus, this example would become:

  .de foo
  .  getopt "foox" "ac:" "--all --check=" \\$@
  .  ...
  ..

> The .getopt command would call the functions `<prefix>-<option>', passing
> the corresponding values as arguments.  `<prefix>-?' (with <option> as
> the argument) is called if <option> is invalid.  Finally, all
> non-option arguments are passed to a macro called `<prefix>'.
>
> Calling the above function like this
>
>   .foo -a -c bar --all --check=urgh --xxx arg1 arg2
>
> would consequently call the functions
>
>   .foox-a
>   .foox-c bar
>   .foox--all
>   .foox--check urgh
>   .foox-? --xxx
>   .foox arg1 arg2

So, basically the user's macro implementation would become very similar to my 
original suggestion, simply offloading the option parsing loop within my 
.pdfhref-L macro to the .getopt request, but retaining everything else much 
the same, perhaps with some changes in the naming convention for the option 
handler macros being required to fit the .getopt paradigm.

This is not to say that a .getopt request is unnecessary -- indeed, it would 
offer significant advantages, amongst which:

  -  the user is relieved of the onus for providing the parsing loop, with
     its associated need for shifting the arguments, (and the requirement for
     maintaining an 'argc' register, to control the shifting process).

  -  the set of options considered 'valid' is more clearly, and rigidly,
     defined.

  -  a mistyped option can be trapped, and diagnosed, rather than simply
     accepting it as the first non-option argument;  this is a major weakness
     in the sample implementation I provided -- not impossible to achieve
     without a .getopt request, by using the .substring request instead, to
     check for '-' at char 0 of \\$1, but it would make the option parsing
     loop rather more complex.

> It probably makes sense to provide a .gnu-getopt request also to
> reorder the arguments.

I'm not sure I understand the need for this, unless you mean to support 
intermixing of option and regular arguments, in any order -- but could a 
simple .getopt request not provide this capability in any case?  Perhaps a 
register, say \n[getopt-strict], could be used to select between strict and 
flexible ordering, if a need for this is perceived.

Best regards,
Keith.