TODO

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