TODO

   1                                                         -*- mode: outline -*-
   2
   3 * Have a look at CMUCL
   4 It has built-in search-lists and wildcard match that could be useful for the
   5 path options.
   6
   7 * Provide a do-cmdline-option (without the s) macro
   8 for repeatedly getting one specific option (and doing BODY on it) until none
   9 is left on the command-line. This could be useful for processing options
  10 appearing several times (for instance, some programs like to have several
  11 calls to -v in order to increase the verbosity level).
  12
  13 Maybe also provide a getopt-last, or a key to getopt that would trigger
  14 warnings if an option is used several times but it's not supposed to. In such
  15 a case, the key would let the programmer decide on whether to discard the
  16 first or last ones.
  17
  18 * Support for option aliases
  19 An option could have several names instead of just one.
  20
  21 * Support for multiple environment variables
  22 An option could be associated with a list of environment variables instead of
  23 just one. Possible uses would be handling both DEBUG and NDEBUG (see below),
  24 but also program-specific versions of otherwise general variables, like trying
  25 MYPROG_NDEBUG first, and NDEBUG next.
  26
  27 * Support for value post-processing
  28 I'm especially thinking about multiple environment variable support, but maybe
  29 elsewhere. For instance, we could implement a --debug opton associated with
  30 a DEBUG env var, and also/or with a NDEBUG env var for which we should
  31 complement the conversion. Now the question is do we want to post-process the
  32 conversion value, the initial string value, or both ?
  33
  34 Another related thought: value post-processing could mean value
  35 canonicalization (especially useful when in the debugger, you're invited to
  36 provide another value). For instance, in path options, the converter handles
  37 ~/ abbreviations. However, this is not valid when typing a value directly,
  38 which is a shame.
  39
  40 And another post-processing-related idea: a :variable property to
  41 automatically setf a variable to the value of an option once it is retrieved.
  42
  43 Now if all options have post-processing, a simple (do-all-cmdline-options)
  44 macro could do all the work (just getopt and execute the associated
  45 post-process).
  46
  47 * Support for resource files ala X11
  48 This could be used to provide values for options depending on the
  49 application's class/name.
  50
  51 * Treat empty env vars as options called without their (optional) argument
  52 With the restriction that there's no notion of an env var set without
  53 argument. There's only empty arguments. This will lead to problems if the
  54 option is supposed to accept empty strings.
  55
  56 * Support for dynamic default value / fallback
  57 computed at run-time from a lambda expression for instance. But is this
  58 different from supporting post-processing ?
  59
  60 * Improve advanced usage support
  61 Maybe we need a way to support declarative definition of a synopsis *tree* for
  62 applications wanting to do things like "prog [options] cmd [options]" or even
  63 more complicated stuff.
  64
  65 There is also the problem that built-in options are duplicated every time we
  66 create new contexts (see section 5 "Advanced Usage" in the Clon User Manual).
  67 We would like those built-in options to apply on all sub-contexts (hint: we
  68 need a true notion of sub-context), but also with the ability to be overridden
  69 in those sub-contexts. This could also be extended to non built-in options.
  70
  71 * Extend abbreviated option matching to dash-parts
  72 e.g. --f-n == --family-name.
  73
  74 * Extend the path option class to accept wildcards in pathnames
  75 and expand them into actual directories.
  76
  77 * Extend the path option class to not ignore a final colon
  78 Like TeX variables, this would mean to append the built-in path after the
  79 user-specified part.
  80
  81 * Study POSIX behavior for cmdline options
  82 See if we can provide a POSIX compliant mode, that would be triggered by
  83 POSIXLY_CORRECT, POSIX_ME_HARDER, or other means (cmdline options?)
  84
  85 * Support for shell completion
  86 Implement automatic generation of whatever is needed for shell completion of
  87 options (zsh in particular, zcomp I think it is).
  88
  89 * Finer grain for conversion errors
  90 Currently, converters are supposed to raise an invalid-argument error, but we
  91 might want something more powerful (like handling a whole conversion-error
  92 hierarchy). For instance, when a path is wrong, we would like to provide a
  93 restart for modifying just the faulty path element. However, this is not
  94 currently possible because invalid-argument errors are trapped and converted
  95 to invalid-cmdline-argument or invalid-environment-value ones. So we can't
  96 benefit from all the restarts that we could define at the lower-level.
  97
  98 * Better detection of short packs
  99 When parsing a short call, we try a known option, a known option with a sticky
 100 argument, a pack, and then barf. Sometimes, a pack can be mistaken for a known
 101 option with a sticky (however invalid) argument. For instance, suppose we have
 102 a -d switch and a -v flag. Using -dv will lead to an invalid argument to -d,
 103 whereas the user probably meant -v -d (or -vd which works). We could improve
 104 the detection of this situation by catching the invalid argument error, and
 105 then trying a pack instead of immediately reporting the error.
 106
 107 * Better advertisement of short packs
 108 [ See also above ] When Clon computes the pack string for the synopsis, we
 109 should put flags first in the pack, because it does not make nay sense to
 110 start a pack with a valued option (the pack would be seen as an option with a
 111 sticky argument first).
 112
 113 * Extend the [items-]separator face property
 114 Item separation would ideally depend on what's before or/and after the item
 115 being displayed.
 116
 117 * Special --no-<name> option for switches
 118 (and probably switch-based options).
 119 For instance, you would have -d / --debug and +d / --no-debug.
 120
 121 * Support help string formatting for more than ttys
 122 For instance, it would be good to be able to generate texinfo, man (groff)
 123 etc. Currently, it is not very clear to me where exactly the limit between
 124 themes and format "drivers" stands. I think that what's in a theme depends on
 125 the driver you use (e.g. colors make sense for a tty driver, but not for a
 126 groff one).
 127
 128 * Support for GUI-based options browsing
 129 I'm quite proud of this idea ;-) Joe uses program for the first time, so he
 130 types "program --gui-help" and gets a GUI with all available options, their
 131 help strings as bubbles, the possibility to select them, provide values etc.
 132 He plays around and then clicks "Go", and the program continues with with the
 133 appropriate command-line (you can already have different contexts in CLon).
 134 Cool hey ?
 135
 136 * Provide a negated long form as well ?
 137 ++debug
 138
 139 * Store all release names in a hashtable
 140 and provide a short bio, with option --clon-about=RELEASE