[Flex-devel] scanopt rework?

[Kang-Che S. <exp...@gm...>]

The scanopt.c and optspec_t interfaces in Flex, as far as I have seen,
resembles other option parsing inferfaces such as argp_parse and getopt_long
from GNU libc. However, IMHO the scanopt interface in Flex is a poorer design
comparing to the two aforementioned GNU interfaces.

Now, I'm not sure if I'm allowed to make pull requests that modifies the
scanopt interface to match one of the GNU interfaces above.

All three interface are required to maintantain a table of long options, which
I think can reside in option.c as before. The differences among the interfaces
are the table fields used.

The current scanopt uses this:

  struct optspec_t {
      const char *opt_fmt;
      int         r_val;
      const char *desc;
  };
  // Example entries:
  // {"--tables-file[=FILE]", OPT_TABLES_FILE, "write tables to FILE"},
  // {"-o FILE",              OPT_OUTFILE,     "specify output filename"}

  // Leading dash or dashes is required, and determines whether option is short
  // or long.
  // The presense of '[' or '=' in opt_fmt string determines whether the option
  // takes an optional or required argument.
  // The desc field is currently unused in Flex.

The Argp Parser uses this as option entry:

  struct argp_option {
      const char *name;
      int key;         // If isascii(key), this also specifies short option.
      const char *arg; // Descriptive name of the option argument, if the
                       // option accepts one. Shown in --help output.
      int flags;       // OPTION_ARG_OPTIONAL or OPTION_ALIAS
      const char *doc; // Description. Shown in --help output.
      int group;       // Option group number (uses for sorting in --help).
  };
  // Example entries:
  // {"tables-file", OPT_TABLES_FILE, "FILE", OPTION_ARG_OPTIONAL,
  //    "write tables to FILE",    0},
  // {"outfile",     'o',             "FILE", 0,
  //    "specify output filename", 0}

  // Pro:
  // Internally accepts '--help' option and can format and print the help text
  // from the table.
  // Cons:
  // 1. Complex interface. Requires and calls a user subroutine for further
  //    option processing instead of "returns when an option is found".
  // 2. Interopability with gettext is unknown and undocumented (dammit GNU!)

getopt_long() uses this as option entry:

  struct option {
      const char *name;
      int has_arg;     // no_argument, required_argument or optional_argument
      int *flag;       // If non-NULL, sets (*flag = val)
      int val;         // Return value.
  };
  // This structure specify long options only. Short options are specified the
  // same way as getopt() and not in this struct.
  // Example entries:
  // {"tables-file", optional_argument, 0, OPT_TABLES_FILE},
  // {"outfile",     required_argument, 0, 'o'}

  // Pro:
  // Simpler structure. Doesn't care about output of '--help' or '--version'.
  // Con:
  // The "flag" field is not so useful (a poor design from GNU).

I'm not proposing to switch Flex's argument parser to use one of the GNU
interfaces. However, I would like to reserve the opportunity to be compatible
with one of them. Flex's options structure has an unused "desc" field, and
"opt_fmt" required internal pre-processing to be useful in scanopt(), which is
ugly IMO.

My questions are these:
1. Will a pull request that may modify the optspec_t structure and the option.c
   entries be accepted?
2. If accepts such a pull request, should I keep the description field in
   optspec_t and the scanopt_usage() function when possible, or is it fine to
   remove them altogether? (I personally prefers to remove, as they
   unnecessary complicates the translation.)